AI Liability After 2027: No CFO Will Let AI Decide Alone

An algorithm can't cover legal fees, serve a prison sentence, or stand before a board of directors. Yet at many companies, algorithms are increasingly the ones making credit decisions, screening job applicants, and setting prices — autonomously, at scale, with no one reviewing each individual call. That's exactly where a gap opens up, one that becomes legally measurable starting in 2026/27: the gap between what machines decide and what humans are held accountable for.

For CTOs, this isn't an academic question. Whoever owns an automated decision system — credit scoring, hiring, dynamic pricing — quickly becomes the focal point when something goes wrong. Not the company as an abstract entity, but the specific person who introduced, configured, and signed off on the system. Meanwhile, pressure from the top is mounting: the CFO wants efficiency gains from automation, the board wants compliance evidence, and technical leadership is caught in the middle.

This article explains why documented human sign-off processes won't be a bureaucratic checkbox after 2027 — they'll be the single most important tool for avoiding personal liability. And why no CFO who understands what's actually on the line will let an AI system make the final call alone.

The EU AI Act has been in force since August 2024, but its impact rolls out in stages. Bans on unacceptable AI practices have applied since February 2025, and obligations for general-purpose models kicked in as of August 2025. The real inflection point for most companies, though, arrives with the full application of the high-risk obligations under Annex III starting August 2026 — with the final stage for AI systems in regulated products landing in August 2027. That's the window where a regulatory announcement turns into an enforceable set of obligations.

What actually falls under Annex III? Exactly the systems that mid-market and enterprise companies already have running in production: credit assessment and credit scoring, AI-driven hiring and applicant screening, employee performance evaluation systems, and insurance risk assessment. Anyone operating these systems qualifies as a "deployer" under the regulation — with their own set of obligations, regardless of whether the system was purchased or built in-house. In our project work with mid-market financial services firms, we keep running into the same blind spot: many companies know exactly which systems they're running, but have no idea they've already taken on deployer obligations — often without ever making that decision consciously.

The penalties blow past anything companies know from the data privacy world:

• Up to €35 million or 7% of global annual revenue for prohibited AI practices — whichever is higher (Art. 99 AI Act)
• Up to €15 million or 3% of global annual revenue for violations of high-risk obligations
• For comparison: GDPR caps out at €20 million or 4% — the AI Act's top tier is nearly double that

But the real paradigm shift isn't in the numbers. GDPR regulates how data gets processed. The AI Act, for the first time, regulates the decision-making process itself: How does an automated decision get made, who's monitoring it, how is it documented, and can a human effectively override it? That's a fundamentally different category of regulation. A company can be fully GDPR-compliant on data handling and still be in massive violation of the AI Act because of the decision system running on top of that data.

For boards, that changes the core question. "Is our data clean?" isn't enough anymore. The question now is: "Can we explain, monitor, and — if needed — stop every automated decision we make?" And that immediately raises the next question: who in the organization is personally on the hook if the answer is no.

Here's a fact that catches many executives off guard the first time we raise it in compliance workshops: officer and director liability doesn't carve out an exception for automation. Germany's Stock Corporation Act (§ 93 AktG) for management board members and the GmbH Act (§ 43 GmbHG) for managing directors require the "diligence of a prudent and conscientious business leader" — and that duty of care extends to every system making decisions on the company's behalf. An executive who pushes a credit-scoring model into production without adequately vetting and monitoring its risks is potentially violating their organizational duty. The fact that the bad call came from a model changes nothing.

The burden of proof is where this gets especially dangerous. § 93(2) sentence 2 AktG flips it: the plaintiff doesn't have to prove the board acted negligently — the board has to prove it exercised the diligence of a prudent manager. Applied to AI systems, that means: in a dispute, the company has to actively demonstrate that the system was tested before deployment, that risks were assessed, and that monitoring mechanisms existed and actually worked. Companies that can't produce that evidence lose the case — regardless of whether negligence actually occurred.

This is exactly where the CTO ends up in the crosshairs. Traditionally, liability suits against corporate officers targeted the CEO and CFO. But with automated decision systems, the picture shifts: the CTO is the one who owns the technical architecture, chose the models, and signed off on the systems. Plaintiffs — whether harmed customers, rejected job applicants, or the company itself after a fine — will increasingly ask: who approved this system? Who knew about its weaknesses? If the CTO holds an officer role (say, as managing director of a GmbH), they're directly liable under § 43 GmbHG. If they're a senior employee rather than an officer, the company can still pursue indemnification claims, with employment-law consequences attached.

So the liability chain doesn't dead-end at the algorithm — it runs from the algorithm through the person technically responsible straight up to the executive suite. Exactly how that chain plays out in any given case hinges on a preliminary question where many decision-makers are dangerously mistaken: the assumption that the AI itself can somehow count as the one making the decision.

It might be the most expensive illusion in the entire automation debate: the belief that handing a decision to a system also hands off the responsibility for it. Legally, it's the exact opposite. AI systems have no legal personhood in the EU. They can't sue, can't be sued, and can't be held liable. The idea of an "electronic person," briefly floated by the EU Parliament back in 2017, was scrapped — and with the AI Act, European lawmakers have settled the question for good: accountability sits with people and organizations, not software.

Article 14 of the AI Act spells this out directly. High-risk systems must be designed so they can be "effectively overseen by natural persons." And effective means a lot more than a dashboard full of green checkmarks. The person providing oversight has to understand the system's limitations, recognize automation bias, correctly interpret its outputs, and be able to intervene or shut the system down when something looks off. A person who simply rubber-stamps whatever the model recommends doesn't meet that bar — and the regulation calls out this exact failure mode by name.

Two real-world cases make clear just how far-reaching this issue is — and every CTO should know both. In the Netherlands, the District Court of The Hague ruled in February 2020 that SyRI, a government risk-scoring system, was unlawful because it flagged welfare recipients as fraud risks through an opaque, unaccountable process. The related child benefits scandal — where an algorithm wrongly tagged tens of thousands of families as fraudsters — brought down the entire Dutch government under Mark Rutte in January 2021. In the US, State v. Loomis, centered on the COMPAS risk-assessment software, established that courts may allow algorithmic risk scores as input, but final judgment stays squarely with the human judge. In neither case did "the algorithm" answer for anything. The people and institutions behind it did.

The parallel to the debate over autonomous vehicles makes this principle easy to grasp. Even in highly automated driving, liability doesn't fall on the vehicle — it falls on the owner and the manufacturer. Germany's Road Traffic Act actually created a formal oversight role for Level 4 vehicles: a human tasked with monitoring the system and taking responsibility for it. Nobody would seriously suggest putting a car on trial. So why would a credit-scoring model be any different?

In court, "the AI made the call" isn't a defense — it's a confession. It's an admission that nobody was actually watching. And if responsibility can't be outsourced, then designing the sign-off process becomes one of the most important jobs a leadership team has.

Here's the counterintuitive twist: the documented human sign-off that many tech teams treat as a bottleneck is actually the most effective personal protection a CTO can have. Anyone who can prove that every critical decision went through a defined, logged approval process holds exactly what the reversed burden of proof demands in a dispute: positive evidence of diligent conduct.

The four-eyes principle isn't a paperwork relic—it's a precise evidentiary tool. When a credit denial above a defined threshold gets reviewed by a second person and approved with a timestamp, reviewer name, and rationale, that creates a record proving three things: a process existed, the process was followed, and a qualified person actually questioned the system's output. Those three points are exactly what decide liability cases.

The key is calibration. No one can—or should—manually review every automated decision; that would wipe out the efficiency gains automation delivers in the first place. A resilient approval process therefore draws clean distinctions:

1. Classify standard cases: Decisions with low damage potential and high model confidence run fully automated — with spot-check reviews at fixed intervals.
2. Set threshold values: Beyond defined limits — loan amount, confidence score, deviation from historical patterns — the decision automatically escalates to human review.
3. Assign review roles: For every escalation tier, it's specified by name which role, with which qualifications, grants approval — and who serves as backup.
4. Document sign-off: Every human decision gets logged tamper-proof with justification, timestamp, and identity — especially when the human overrides the system.

The legal parallel here is the Business Judgment Rule (§ 93 Abs. 1 Satz 2 AktG in German corporate law): An executive isn't liable for a bad business call if they acted on reasonable information in the company's best interest. Applied to AI, that means liability doesn't stem from a single wrong model output — it stems from the absence of a sound decision-making and oversight process. The sign-off process is essentially the Business Judgment Rule, operationalized for the age of automated decisions.

And here's the contrarian take you rarely hear in board meetings: yes, documented sign-off processes cost money — staff, tooling, slower turnaround. Some CFOs run the numbers internally and conclude that fine risk can simply be "priced in." That math is wrong on two counts. First, it ignores that officer liability hits personal assets — no balance sheet reserve fixes that. Second, it underestimates the reputational damage a public algorithm scandal can cause, as the Dutch child benefits scandal demonstrated in brutal fashion. Sign-off processes may look more expensive than fines on paper — but they're far cheaper than personal liability.

That said, an approval process is only as solid as the technical foundation underneath it. A four-eyes principle sitting on top of a system that doesn't log its own decisions is just theater.

The AI Act's technical requirements are surprisingly specific. Article 12 requires high-risk systems to automatically log events "over the entire lifecycle of the system" — deployers must retain these logs for at least six months, with longer retention periods in regulated industries like financial services. For CTOs, that means logging is no longer a debugging feature. It's a legal obligation with defined minimum content: usage periods, input data references, and the identities of anyone involved in reviews.

In practice, four technical building blocks have emerged as the foundation for defensible evidence:

• Complete decision logs: Every system output gets stored immutably with its input reference, model version, confidence score, and timestamp. Append-only storage or WORM (write-once-read-many) systems prevent after-the-fact tampering — the first thing courts and expert witnesses check.
• Explainability tooling: Methods like SHAP or LIME make it possible to trace which factors drove a specific decision. This isn't just good data science — it's practical legal protection. If you can explain *why* a loan application was denied, you can also demonstrate that no prohibited characteristics factored into the outcome.
• Industry-standard model documentation: Model cards and datasheets document a model's purpose, limitations, training data provenance, and known weaknesses — the baseline for any conformity assessment.
• Data and model versioning: Training data, feature pipelines, and model weights need to be versioned so that any historical decision can be traced back to the exact model state that produced it. Tools like DVC or MLflow are already standard here — what matters is that versioning is directly linked to the decision logs.

That last point is chronically underestimated. A model retrained monthly is, from a legal standpoint, twelve different systems per year. If a rejected job applicant files suit in 2028, the CTO needs to be able to reproduce the exact model state from 2027 — including the training data used at the time. Without that, you're standing in court with the burden of proof reversed against you and nothing to show for it.

The problem gets worse for systems built on third-party models: the deployer is liable for how the system is used but doesn't control the model's internals. That makes contractual guarantees from the vendor — and your own input/output logging — even more critical. For a concrete look at what an auditable architecture like this looks like in practice, see our financial.com project, where we designed AI automation from day one around fully traceable data flows — a principle we build into every engagement in Software & API Development.

But this technical foundation only delivers real protection once it's tied to financial accountability at the organizational level. Logs that nobody budgets for, reviews, or actually factors into decision-making are dead weight.

The old split — the CTO builds, the CFO pays — no longer holds up for high-risk AI. The reason lies in the asymmetric distribution of risk: the CFO carries the financial exposure of a bad decision (fines, damages, provisions), while the CTO carries technical responsibility for the system that made that decision. Neither one can assess the full risk alone — which is exactly why joint sign-off on critical AI systems is becoming the new normal.

In practice, the collaboration shifts in three concrete ways:

First: Shared risk thresholds. The question of at what damage potential a human must step in isn't a purely technical variable. The CTO can point to the model confidence level at which the error rate climbs — but only the CFO can put a number on what a mispriced major contract or a string of discriminatory rejections actually costs the company. Escalation thresholds need to be defined jointly and reviewed jointly on a regular basis. A quarterly workshop where the CFO and CTO check thresholds against real incidents and error statistics is time well spent.

Second: Compliance becomes a line item, not an afterthought. Logging infrastructure, explainability tooling, audit staff, and third-party conformity assessments all cost real money. If these items are left to "ride along" inside the general IT budget, they'll be the first thing cut in every belt-tightening round — right up until something goes wrong. Budgeting AI compliance as its own line item, owned by the CFO, isn't a bureaucratic formality — it's the organizational proof that the company takes the risk seriously. And in a dispute, that's a due-diligence record in itself.

Third: Mutual reporting obligations. The CTO needs to keep the CFO informed about model changes, drift alerts, and unusual spikes in errors — and the CFO needs to keep the CTO in the loop on new regulatory requirements, insurance conditions, and audit priorities. Where that communication breaks down, you get exactly the kind of uncontrolled gray zones we described in our piece on shadow AI in business units: systems leadership only learns about once something's already gone wrong.

A compliance lead at a German financial services firm summed it up well in a conversation with us: "The question isn't whether the AI makes good decisions anymore. The question is whether we can prove we knew what it was doing — at every single point in time." Building that proof is a joint effort between tech and finance. In the projects we support in AI & Automation, this exact interface between CFO and CTO is consistently where governance initiatives either become sustainable or fall apart: building automation so it stays auditable from both sides.

That this collaboration isn't just an internal nice-to-have becomes obvious the moment outside parties start scrutinizing that same interface.

The toughest enforcers of the AI Act may not sit in Brussels at all — they sit in the underwriting departments of D&O insurers. Directors-and-officers policies protect the personal assets of board members, and insurers have a very direct financial stake in making sure the executives they cover don't take on unmanaged AI risk. The consequence is already showing up in renewal cycles: questionnaires on AI usage and governance processes are becoming standard, and companies that can't produce documented sign-off and monitoring processes should expect higher premiums, exclusions for AI-related claims, or outright rejection of the risk.

Here's the part that stings: missing documentation can jeopardize coverage retroactively, too. D&O policies routinely include duties and exclusions for knowing breaches of obligation. A company that runs a high-risk system without the legally required human oversight — despite being aware of the rules — risks exactly that classification, and ends up with no coverage when it matters most. The bitter irony: the policy meant to shield executives from personal liability fails precisely in the scenario it was purchased for.

At the same time, annual audits are shifting. External auditors evaluate a company's internal control system as part of the audit — and when automated systems drive decisions with financial statement impact (credit approvals, receivables valuation, dynamic pricing that moves revenue), the controls governing those systems become part of the audit scope. Germany's Institute of Public Auditors (IDW) has already set the framework with its audit standard for AI systems, and the major audit firms are building out corresponding review checklists. An AI system without traceable controls can turn into an audit obstacle — with direct consequences for the audit opinion, credit ratings, and financing terms.

For CTOs and CFOs, this adds up to a clear list of what outside parties want to see:

The pattern is impossible to miss: four different external parties are asking for the same thing — documented, human-accountable decision processes. Build these processes once, and you satisfy all four requirements at the same time. Skip them, and you'll face pressure from all four directions simultaneously.

The liability gap this article opened with doesn't close on its own — it gets closed. Not through less automation, but through precisely assignable responsibility. The AI Act doesn't make accountability for algorithmic decisions fuzzier; it makes it more concrete: every high-risk decision needs a human overseeing it, a process documenting that oversight, and a technical infrastructure that can prove it happened. Automation doesn't make human sign-off obsolete — it makes sign-off the single most valuable part of the system, because it's the one mechanism that turns personal liability from an uncalculable risk into a documented safeguard.

For CTOs building these processes now, there's an upside that's easy to miss amid the regulatory deadline rush: establishing sign-off workflows and logging before August 2026 gives you a head start over competitors scrambling to retrofit under time pressure — and lowers your own odds of becoming the test case in the first audit or lawsuit. Historically, the companies that end up first in front of a regulator or a judge are the ones that built their evidence trail last. Whether the CFO and CTO end up sharing this responsibility going forward, or pointing fingers at each other when something goes wrong, won't be decided by the wording of the regulation — it'll be decided by who in the company puts the sign-off process on the table first. No CTO should let a system run under their watch if they can't reconstruct its decisions when it counts.

The concrete next step: this quarter, review which of your automated decision systems fall under Annex III of the AI Act — credit scoring, hiring, and employee performance evaluation are the usual suspects. Set up a logged sign-off process with clear escalation tiers for each one, and get a meeting on the calendar with your CFO to lock in risk thresholds and a compliance budget. The systems you make auditable today are the only ones you'll still be able to run with a clear conscience in 2027.