Business Lawyer + Developer in One Person — the Value for AI Projects

Most AI projects don’t fail because of the model — they fail at the seam between law and IT: the lawyer knows the obligation, the developer knows what’s feasible, but the two speak different languages. Combining both in one person closes that seam. That is the concrete value this article is about. (As of December 2025. Professional analysis, not legal advice for individual cases.)

By Leon Lotz, business lawyer & developer.

The real problem: AI fails at the interface, not at the model

It’s a common misconception that AI projects fail because of the technology. Industry findings paint a different picture: a widely cited MIT analysis puts the failure rate of AI pilot projects at around 95% — and the causes lie predominantly not in the model, but in inadequate preparation, data silos, and a lack of coordination. Another assessment locates nearly half of all failures in coordination between the parties involved, not in feasibility (Materna; IT-BOLTWISE).

The core issue: law and IT work on an AI project using two different vocabularies. The lawyer formulates a requirement — “personal data must not train the model” — and the developer translates it into architecture. At each of these handoffs, a translation loss occurs: the legal obligation is cast into code too late, incompletely, or simply incorrectly. The developer doesn’t understand the obligation in depth, the lawyer doesn’t know what’s technically feasible. It is precisely in this gap that projects stall and compliance risks emerge.

This seam is not a minor detail. It is the most expensive point in the project — because it runs through every phase, from tool selection to acceptance.

How the market solves it — and why that stays expensive

The market has found an answer to the interface problem. That answer is organizational, never personal: it puts more people at the seam instead of removing it.

The law firm: advises but doesn’t build

Law firms and data protection consultants assess AI initiatives cleanly from a legal standpoint — on GDPR, the AI Act, data processing agreements. What they don’t do: build software. Their recommendation leaves the firm as a document and has to be implemented by someone else. The translation — and its loss — remains; it is merely outsourced.

The agency: builds but doesn’t own the law

AI agencies and developer teams deliver the implementation. “GDPR-compliant” and “legally watertight” are often a marketing claim there, one that doesn’t replace a proper legal assessment. The legal responsibility ultimately rests with the client — or with the law firm they’ve separately retained. Two camps again, a seam again.

The interdisciplinary team: solves it — with coordination overhead

The most sophisticated market response is the interdisciplinary team with defined roles, sometimes including an “AI Compliance Officer,” that brings together compliance, data protection, IT, and legal. This works — but it manages the interface rather than dissolving it. Every coordination round costs time, every handoff a piece of clarity about who’s responsible. Mid-sized initiatives not infrequently work with three to five service providers in parallel, and every handoff costs time, money, and clear accountability.

All three models are legitimate and right for many constellations. They simply share the same blind spot: they take the seam as a given.

Handoffs between law firm, AI agency and project team as breaking points versus continuous ownership of law and technology from a single source

Every handoff between law and IT is a potential breaking point. From a single source it disappears — one line instead of many seams.

The alternative: law and technology from a single source

“From a single source” here means precisely this: one responsible person for both the legal assessment and the technical implementation. Not two service providers with a shared kickoff. Not a team that coordinates. One person who understands the legal obligation and casts that very standard into code themselves.

What this concretely eliminates:

No translation loss. The obligation doesn’t have to be translated from legal into tech language and back — it is conceived directly as a technical decision.
No retrofitted compliance. Data protection and risk class are settled before the first data model, not after.
No shifting of blame. There is no point at which “the other department said so” can serve as an explanation for a gap.

This is not a theoretical advantage. It shows up exactly where law and technology meet in the project.

Where the dual qualification concretely pays off

In every phase of an AI project there is a moment when a legal question forces a technical decision. When both competencies sit in one person, the decision is made immediately and correctly — instead of in a coordination loop.

Tool and model selection: DPA and third-country transfer, before the tool is chosen

Which AI tool is even permitted? As soon as personal data flows, a data processing agreement is required (Art. 28 GDPR), and with US providers the third-country question arises (Chapter V GDPR). This question is not settled: the EU General Court upheld the EU-US Data Privacy Framework on 3 September 2025 (Case T-553/23, Latombe), but that decision is under appeal before the Court of Justice (as of December 2025) (DLA Piper). Whoever thinks law and technology together checks this before the tool is locked in — not once the tool is already built in.

Architecture and data model: privacy by design in the code

Art. 25 GDPR requires data protection by design. That is not a documentation task but an architectural decision: data minimization, separation, and deletion concepts belong in the data model — at the first draft, not as a retrofit. This is exactly where it pays off that the same person knows the obligation and writes the schema.

Feature scoping: determine the AI Act risk class up front

Before a feature is built, it should be clear which risk class under the AI Regulation it falls into — because obligations and entire feature sets hinge on it. The AI Regulation (Regulation (EU) 2024/1689) has been in force since 1 August 2024 and applies in stages: prohibited practices and AI literacy since February 2025, GPAI obligations since August 2025, transparency obligations (Art. 50) from 2 August 2026. The comprehensive high-risk obligations (Annex III) are to be postponed to 2 December 2027 under the “Digital Omnibus” package presented in November 2025 — but that package is not yet in force (DataGuard; SRD Rechtsanwälte). Whoever clarifies the risk class before scoping the feature doesn’t build past an obligation. I cover the concrete deadlines and risk classes separately: EU AI Act — what companies must do now.

Evidence and acceptance: documentation, DPIA, contract for work

At the end stand demonstrability (where applicable, a data protection impact assessment under Art. 35 GDPR), documentation, and the contract itself — Werkvertrag (German contract for work, sec. 631 BGB), usage rights, liability. Whoever wrote the code and knows the legal requirements documents in an audit-proof way, rather than reconstructing after the fact.

Classic setup vs. single source: the direct comparison

Criterion	Law firm + agency (separate)	Interdisciplinary team	Single source (lawyer + developer)
Responsibility	split, often unclear	bundled within the team	bundled in one person
Translation loss law ↔ IT	high (two camps)	reduced, but present	eliminated
Timing of compliance	mostly retrofitted	parallel	by design, from the start
Coordination effort	high	medium to high	minimal
Clarity of point of contact	several	one team	one person
Speed on legal questions in the sprint	slow (external query)	medium	immediate
Fit for PII / high-risk projects	only with tight steering	good	very good

The comparison is not meant to disparage the other models — they have their place. It only shows which trade-off you’re buying into in each case.

Honest limits: when do you not need this?

The personal union is no cure-all, and it would be dishonest to sell it as one.

You don’t necessarily need it when a purely technical prototype with no personal-data reference whatsoever is being built, when both competencies are already tightly interlocked within the company, or when a very large initiative maintains its own legal and dev teams with well-rehearsed processes.

And a second, equally important limit: a business lawyer (Wirtschaftsjurist) is not an admitted attorney (Rechtsanwalt). Comprehensive legal advice — in particular representation in contentious matters — remains reserved for fully qualified lawyers with bar admission; this follows from the German Legal Services Act (Rechtsdienstleistungsgesetz, RDG), which grants no comprehensive advisory authority below the bar (Munich Bar Association on the RDG). The value of a business lawyer is not in replacing a law firm, but in compliance-, data-protection-, and contract-focused project ownership and in the ability to implement legal requirements directly in technical terms. Where a contentious legal question arises, an admitted attorney should be brought in — and it is precisely that interface that can be cleanly organized.

This honesty is not an admission of weakness but part of the value: an advisor who knows the limits of their role is more reliable than one who promises everything.

Conclusion: one seam fewer is one risk fewer

AI projects predominantly fail at coordination, not at the technology. Every seam between law and IT is a potential breaking point — for delays, for translation errors, for compliance gaps. Combining law and technology in one person removes that one seam. It doesn’t solve every problem of an AI project. But it takes one of the most expensive ones off the table from the outset.

Frequently asked questions

Why should law and technology sit in one person on an AI project? Because a translation loss occurs at every handoff between lawyer and developer: the legal obligation gets implemented too late or incorrectly. When both sit in one person, the legally driven technical decision is made immediately and correctly — without a coordination loop and without retrofitted compliance.

What do AI projects really fail at — technology or coordination? Predominantly coordination. Industry findings locate the majority of failed AI pilot projects in inadequate preparation, data silos, and a lack of coordination between the parties involved — not in the technical feasibility of the model.

What distinguishes “from a single source” from an interdisciplinary team? A team manages the interface between law and IT with coordination rounds and handoffs. “From a single source” removes the interface, because one person owns both the legal assessment and the technical implementation. That saves coordination effort and makes responsibility unambiguous.

Isn’t it enough to retain a law firm and an agency separately? For many initiatives, yes. The price is the seam in between: the law firm advises but doesn’t build; the agency builds but doesn’t own the law. The translation and the liability risk at the interface stay with the client. From a single source, that friction point disappears.

Is a business lawyer a “real” lawyer for these questions? A business lawyer (Wirtschaftsjurist) specializes in business-, contract-, and compliance-related legal questions, but is not an admitted attorney. Comprehensive legal advice in contentious matters remains reserved for attorneys (RDG). The value lies in compliance- and data-protection-focused project ownership and the direct technical implementation — not in replacing a law firm.

Sources — as of 25.12.2025

Note: Statutory deadlines and risk classes (AI Act, GDPR) are as of December 2025 and partly in a state of legislative flux (Digital Omnibus). Before making concrete project decisions, verify against the primary sources (EUR-Lex, the statutory text). This article is a professional analysis. This is general information, not legal advice.