AI governance for development teams: what I learned from someone who’s already rolled it out

I thought AI governance was legal’s problem. I walked out with a list of things I need to change about how I build software.

FRANK LACROIX
Software Engineer

When I saw the title of the Knowledge Sharing session, I assumed the content would barely graze me. I build agents and systems with LLMs: my job is making things work, not managing regulatory frameworks. AI governance for development teams struck me as, plainly, another department’s problem.

The session was led by Beatriz G. Pozo, a Project Manager with more than ten years of experience and three of them rolling out AI governance models at large corporations. Within the first ten minutes, I understood why I was wrong.

The EU AI Act isn’t about paperwork: it’s about what you build

The EU Artificial Intelligence Act —the world’s first comprehensive legal framework for AI— comes fully into force in August 2026. Companies can be audited from that date onwards, with fines of up to €35 million or 7% of global turnover. The point of those penalties is to make compliance real rather than merely formal: because what the law assesses isn’t whether risk is present in your project, but whether you’ve taken concrete steps to manage it.

What surprised me most is the logic the law uses to classify risk. It isn’t defined by the project’s name or the technology you use, but by what your system does and the context it operates in. Beatriz nicknamed it the risk-o-meter, and it has four levels —from lowest to highest risk:

• Minimal risk: internal automations with no direct human interaction and no decisions that carry real impact.
• Limited risk: most projects involving human interaction, virtual assistants included. The core requirement is algorithmic transparency: the user has to know they’re talking to an AI.
• High risk: projects in critical sectors such as healthcare, education, infrastructure, or human resources. Exhaustive documentation and strict compliance.
• Unacceptable risk: mass biometric surveillance, psychological manipulation, social scoring by governments. Banned outright. A red line with no nuance.

High risk isn’t the end of the world — there are mechanisms to mitigate it. Beatriz gave an example I kept turning over afterwards: if you build an agent that does mass mailing and you use names and email addresses, you’re handling personal data and the risk goes up automatically. But if users have signed prior consent, the risk goes down. If you anonymize the data as soon as you can, it goes down further. What the law assesses is whether you’ve shown that you asked yourself the risk question and tried to reduce it, not whether you managed to eliminate it.

This lines up with something we already do routinely on AI projects: documenting design decisions not for the archive, but so they’re reproducible and auditable. Governance doesn’t add a brand-new process from scratch. It extends one that, if you work well, already exists.

AI governance for development teams: what changes in how I work

The second part was the one that hit me most directly. Beatriz moved from the regulatory framework to concrete projects, and she did it from the perspective of the team building the thing, not the team supervising it.

The first implication has to do with liability. If you’re the provider developing the AI, the legal liability is yours. If the client puts their name on the system, liability becomes theirs — but the client will come looking for you if something goes wrong. Either way, your cover is documentation: not generic documentation, but answers to specific questions about what your system does.

There are four elements any development team should build into its processes:

1. Negative testing. Don’t just test what the AI should answer — test what it shouldn’t. Unexpected questions, situations with discriminatory potential, edge cases. The goal is to demonstrate that you actively went looking for failures, even if the final system isn’t perfect.
2. Algorithmic transparency. The team has to be able to explain why the system answered what it answered — not to the user, but to an auditor. For limited-risk systems, algorithmic transparency is the Act’s central requirement, not an optional extra.
3. Human oversight. Systems that make autonomous decisions automatically carry a higher risk level, so adding a human review point for decisions with real impact lowers that level directly. Don’t see it as a patch — see it as an architecture decision.
4. Traceability. Who ran which test, on what date, with which model, and with what result. Not for the archive, but so you can back it up when someone asks.

Another interesting moment came when our colleague Carlos Jiménez, software architect, asked at what point you can “sleep soundly” about your level of compliance. Beatriz’s answer was more concrete than I expected: when you have an inventory of what you use, you can explain what your system does and, on top of that, you have the tests you’ve run documented. You don’t need a repository running to hundreds of pages — it’s enough to be able to show that you asked yourself the right questions, which is what the law calls due diligence.

The same applies to Shadow AI: the tools team members use outside the official stack, often without anyone knowing. Inventorying them isn’t about policing anyone — it’s about knowing whether someone is sending confidential documents to a tool that uses them for training. It’s the first step towards any real form of control.

Documenting at ultra-agile speed: the problem the law doesn’t fully solve

The question I’d been wanting to ask the whole session was this one: LLMs have accelerated development exponentially. We iterate on models week by week. How do you keep governance up to that pace? If the NIST AI Risk Management Framework or ISO 42001 describe processes designed for slow maturity cycles, what happens when your system changes every week?

The underlying problem, which Beatriz confirmed, is that models aren’t deterministic. You can ask the same question ten times and get different answers. The tests you ran against one model aren’t automatically valid for the next. And documentation that captures a system’s behavior at one specific moment goes stale as soon as the system evolves.

The solution she’s applied is using AI to document and evaluate her own AI projects. In the most recent governance model she rolled out, she built a risk assessment agent trained not on information from the internet, but on the organization’s internal documentation: its ethical frameworks, its risk criteria, its previous design decisions. When a team submits the spec sheet for a new project, the agent evaluates it against those criteria and generates the first draft of the risk documentation.

Don’t go thinking I pull this off on my own. AI helps me, of course.

BEATRIZ G. POZO
Project Manager

I pointed out that reasoning systems aren’t deterministic and you can’t cover every case. Her answer was that legal cover doesn’t require the system to be perfect, only that you can show you tried to make it so. The test suite, the disclaimer to the user, and continuous monitoring are what the law calls due diligence. Another of our engineering colleagues, Nacho Mangas, added a new angle: giving users a way to report problematic answers generates free feedback on top of legal cover. It’s the same principle behind the feedback buttons in commercial assistants: users run continuous testing without anyone asking them to.

What I find most interesting about this approach is that it isn’t extra weight piled on top of the engineering work, but the same logic behind automated tests: not to guarantee there won’t be bugs, but to show we looked for them before shipping. And just as nobody on the team debates whether writing tests is worth it, AI governance should occupy the same mental slot.

The next step I have in mind is to define what minimum documentation each AI project needs at closing, to create our own risk assessment templates —like the ones Beatriz built in Confluence and Notion— and, above all, to fold negative testing into the development process, not as a final step but as part of the cycle from the very beginning.

If you want to explore the full framework Beatriz presented, you can access the session’s slide deck or watch the video below.

Frequently asked questions

Does the EU AI Act affect companies that only use AI internally, without exposing it to customers?
Yes. The Act applies from the moment employees use AI tools in their work, even if there’s no public-facing product at all. The obligation to train employees in the responsible use of AI is one of the requirements already in force.

What if my project is high risk? Does it have to be cancelled?
No. High risk doesn’t prohibit the project: it demands more rigor in documentation and mitigation measures. The key is to identify the risk, take concrete steps to reduce it, and document that process. The law assesses due diligence, not perfection.

How much documentation is enough to be covered?
The law doesn’t specify a volume or a format. What it asks is that you can explain what your system does, why it does it that way, what tests you’ve run, and what measures you’ve taken to reduce the risk. An up-to-date inventory, a documented test suite, and a periodic review process cover most limited-risk projects.