IT Law

§ 1151 ABGB draws the distinction: whoever undertakes to produce a work for remuneration concludes a contract for work; whoever commits to perform services for another for a certain period, a contract for services. Under a contract for work a result is owed, under a contract for services diligent effort – and that determines when payment falls due and what the provider must answer for. In practice, custom software is usually treated as a contract for work, ongoing operation and maintenance rather as a contract for services; what counts, however, is the individual case, not the heading of the contract. We settle this classification before signing – afterwards it is fought over.

Missing points of contact, test data not delivered, approvals not given – in IT projects the delay often lies with the customer. The law gives two answers: under § 1168 Abs 1 ABGB the provider is still owed the agreed remuneration if it was ready to perform and was prevented from doing so by circumstances on the customer’s side; it must deduct what it saved or earned elsewhere as a consequence. Under § 1168 Abs 2 ABGB the provider may also set a reasonable grace period, coupled with the declaration that the contract is deemed dissolved once the period expires without result. We therefore draft cooperation duties so concretely that both sides know what is to be delivered by when.

Yes. Under § 1168a ABGB the contractor is responsible for the damage if the work fails because of the obvious unsuitability of materials supplied by the customer or the customer’s obviously incorrect instructions, and the contractor failed to warn. Applied to IT projects: if the provider recognises that the specifications, the legacy data or the existing system environment are obviously unsuitable, it must say so. If it stays silent, it bears the consequences of the failure; if it warned, they lie with the customer. The duty to warn therefore cuts both ways – and the outcome usually turns on what can be proven. We document warnings and the responses to them in ongoing projects, and reconstruct them when a project has failed.

The statutory default is § 1170 ABGB: remuneration is, as a rule, payable once the work is completed. Where the work is performed in stages, however, the provider may demand a proportionate part earlier – the normal case in IT projects with milestones. The contract can depart from this default, and much is decided there: a contractually agreed acceptance procedure defines when the work counts as completed, how it is tested and what consequences approval carries. We recommend regulating the payment schedule and the acceptance procedure together, so that payment remains tied to demonstrated project progress.

§ 933 Abs 1 ABGB grants two years: the transferor warrants every defect that exists at handover and comes to light within two years thereafter. The resulting claims prescribe three months after that period ends (§ 933 Abs 3 ABGB). Importantly, § 933 Abs 4 ABGB expressly permits the parties to shorten or extend these periods by contract – in contracts between businesses the warranty is therefore often drawn more narrowly than the statute provides. What applies in a specific case is thus decided by the contract, not by one’s memory of the statutory period. We review such clauses before signing – and, in a dispute, first of all.

Between businesses, yes – not to the day, but within a reasonable period. § 377 UGB requires defects that could have been detected by inspection in the ordinary course of business to be notified to the seller; the same applies to defects that only come to light later. Whoever omits the notice loses the warranty claims, damages for the defect itself and the ability to invoke error about the absence of defects – an otherwise intact claim is lost in its entirety. The statute names no fixed number of days; what is reasonable depends on the individual case. We advise recording and notifying irregularities in writing at once, and we draft inspection and notice procedures into contracts so that this question never remains open.

As a rule, yes: as soon as the service provider processes personal data on your behalf – IT support with access to your systems, hosting, cloud storage – Article 28 DSGVO requires a processor agreement. From an IT-law perspective it is one component of the overall contract package: it belongs alongside the service description, the service levels and the arrangements for the end of the contract, so that data and access credentials actually come back at the end. The data protection details are described under our data protection law practice.

Since 2 August 2026 the transparency obligations of Article 50 KI-VO apply: AI-generated or AI-manipulated content, in particular deepfakes, must be labelled, and anyone using a chatbot in customer contact must disclose that a machine is answering – unless that is obvious anyway. Whether a specific publication falls under the labelling obligation depends on its content and use; we assess this against the actual deployment. Infringements are subject to fines.

Article 4 KI-VO has obliged companies since February 2025 to ensure sufficient AI literacy among their staff. This training obligation applies to every company that uses AI systems, regardless of size and sector. The Regulation does not prescribe a particular format; what matters is that employees know the tools in use, their limits and the internal rules. Documented training together with an internal AI policy covers the obligation in most businesses.

A provider develops an AI system or places it on the market under its own name; a deployer uses a system under its own authority in a professional context. Most companies that use tools such as chatbots or image generators are deployers – with transparency and training obligations, but without the more extensive provider obligations. A word of caution: anyone offering a third-party system under its own brand, or substantially modifying it, may move into the provider role. This classification is the first step of any AI advice, because all further obligations depend on it.

A blanket ban is rarely sensible and hard to enforce in practice – the tools are then used anyway, just without oversight. Clear rules work better: an internal AI policy, an approved list of permitted tools and the training required by Article 4 KI-VO. In substance, the key point is: no personal data and no trade secrets are to be entered into services whose processing you do not control. The data protection questions this raises belong to data protection law – the two fields interlock here.

Copyright protects human creations. A result produced purely by machine, without a creative contribution of your own, accordingly enjoys no copyright protection – so in principle third parties may use it too. What you may do with the output is additionally governed by the terms of use of the respective provider. Conversely, an AI output can infringe third-party rights, for instance where it comes too close to a protected work. Much of this has not yet been resolved by the supreme courts; we name the open questions instead of feigning certainty.

The circle is considerably larger than before: instead of around one hundred operators of critical infrastructure, the NISG 2026 covers several thousand companies in 18 sectors – depending on the sector, from 50 employees or EUR 10 million in turnover. Important: there is a duty of self-registration. Anyone who waits for an authority to make contact is already missing the first obligation. Whether a company is covered can usually be clarified quickly on the basis of sector and company size.

Under the NISG 2026, significant security incidents require an initial report within 24 hours, with follow-up reports thereafter. Breaches of the reporting and security obligations are subject to fines, and the Act expressly places responsibility on the management bodies: they must approve the risk-management measures, oversee their implementation and undergo training themselves – delegating to the IT department does not relieve them. A prepared reporting procedure is therefore part of the obligation, not an optional extra.

Yes. The Austrian mandatory disclosures under the E-Commerce Act and the Media Act also apply to business accounts on social media, not only to your own website. In practice, an easily accessible link to the imprint on your website is sufficient, for instance in the profile description. Missing disclosures are subject to administrative fines and hand competitors an easy point of attack – while the effort of putting them right is small. We review website and channels in a single pass.

According to the settled view of the data protection authorities, declining must be as easy as consenting – in practice that means an equivalent reject option on the first layer of the banner, not hidden behind “settings”. Pre-ticked boxes and banners that set cookies before consent is given are not permissible. Often the best solution is the simplest: those who do without dispensable services need no banner at all.