The EU AI Act was a beginning, the way these things usually are. Europe wrote first, everyone read it, and the interesting part started afterwards.
Two days ago that afterwards arrived in Türkiye, the 2026-2030 AI Action Plan was published with sixteen dated actions and a public portal that will publish the owner and status of each one. Elsewhere the picture ranges from South Korea's comprehensive law and China's binding sectoral rules to Brazil's pending bill and Singapore's agentic framework, and the drafting has stopped copying Brussels line for line.
For your company this changes less than it sounds. The EU AI Act alone was already reason enough to build the capability, because this technology was never going to stay inside the jurisdiction you happen to sit in. A model trained somewhere else, hosted somewhere else again, reached through a vendor’s interface in a fourth country, serving your customers in a fifth.
If your company started taking AI governance seriously today, the bad news is that yesterday was already late.
The gap is not principles. It is operating controls.
The American Arbitration Association surveyed senior legal and executive leaders in 2026. The results describe one condition.
Grant Thornton found three in four boards had approved major AI investments while half had set governance expectations. Of about a thousand US senior leaders, 78% were not fully confident of passing an independent AI governance audit within ninety days. Schellman puts fully mature programmes at 27%.
Read those numbers as a description of your own position, because statistically it is. You have approved AI spending. There is a policy somewhere. And if a regulator, a major customer or a plaintiff’s lawyer asked you next month to demonstrate who approved a specific deployment and on what basis, you would be assembling that answer from scratch under time pressure.
This is not a new problem. In Enterprise AI’s Biggest Risk: A Persistent Governance Gap, I argued that enterprises were being asked to treat accountability as more than a vendor’s marketing claim. The question has since become more concrete: can anyone produce the record of who approved a system, changed it, monitored it, or could stop it?
Accountability follows control
Most executives treat AI exposure as a procurement question. You bought a system, the vendor holds the obligations, you hold a contract.
Someone chose to deploy that system, configured it, pointed it at a population and decided how much weight its output would carry. No supplier contract transfers responsibility for the choices your company still controls.
The EU AI Act is the most developed version of this, so read it as a map of what is coming. It gives deployers of high-risk systems duties of their own: use within the instructions, human oversight by someone with the competence and the authority to intervene, monitoring, logs, and notice to workers before such a system reaches their workplace.
South Korea requires oversight and risk mitigation for high-impact AI and reaches foreign businesses through a local representative duty.
China requires lawful data sourcing, labelling and complaint handling.
Sectoral regulators elsewhere are arriving through statutes written decades before AI, because the question underneath is the one liability law has always asked. Who was in a position to prevent this.
The provision that catches companies out is the one that moves the line. A deployer can pick up full provider obligations by putting a bought system on the market under its own name, modifying it substantially, or redirecting it into a use that makes it high-risk.
A team that fine-tunes a purchased system and points it at a new use case can move your company into a category of obligation nobody budgeted for. No purchase order records it. You find out later.
It is who inside your company is allowed to make that kind of change, and whether anyone sees it before it ships.
Governance, compliance, and the difference that costs money
Compliance tests a system against a fixed, existing requirement and produces evidence.
Risk management identifies what could go wrong for a specific system in a specific use.
Governance sets the decision rights. Who approves, who can stop it, what gets escalated, what happens when someone objects.
Ethics without governance has no enforcement. Risk management without governance has no consistency. Compliance without governance answers last year’s question. A system may be compliant with the requirements assessed at launch while its use case, vendor model version, retrieval corpus or permissions have changed beyond the assumptions of that assessment.
The reason AI breaks this harder than previous waves is a property of the systems. Traditional software is deterministic, so you govern it to confirm it functions as specified. AI is probabilistic. It infers, generalises and produces outcomes nobody encoded in advance, so the thing being governed is behaviour rather than function.
A signed policy does not answer who has authority to approve a new use case, suspend a deployment, demand evidence from a vendor, or reopen a risk classification after a material change. I set out what a policy needs in order to bind organisational behaviour in Why Your AI Policy Fails Before Anyone Enforces It.
A compliance function can tell you whether you met the rule. It cannot tell you which of this year’s decisions will look indefensible in eighteen months. Your risk function was built for systems that behave the same way on Tuesday as they did on Monday. Your audit function was built to sample records and interview the people who decided, and there is nobody to interview.
What does not wait for a regulator
The deadline for EU member states to designate national authorities fell on 2 August 2025. As of 17 June 2026, nine of twenty-seven had designated both a market surveillance authority and a notifying authority. Twelve had partial designations. Six had neither. Any programme quietly calibrated to local enforcement capacity collapses the moment designation completes, and four other channels run on their own timetables regardless.
Procurement. Enterprise buyers and public bodies are writing AI conformity questions into tenders now, on the original timeline, because their own counsel will not accept a supplier’s assurance that a deadline shifted. Revenue is lost before an inspector is ever involved.
Litigation. Courts have not settled whether an AI developer owes users a duty of care, and the pattern so far suggests they will not settle it soon. A Florida federal court let negligence and product liability claims proceed against a chatbot company in 2025; five related cases then settled together in January 2026 with terms undisclosed. You cannot price a liability nobody has defined, your insurer cannot either, and discovery arrives long before any court reaches a view.
Supply continuity. When China’s rules on anthropomorphic interactive services took effect on 15 July, ByteDance’s Doubao and Alibaba’s Qwen closed or restricted user-created and anthropomorphic agent features. The companies’ notices referred to product adjustments; the timing and scope coincided with the new rules, but neither company publicly framed the change as a refusal to comply.
Insurance. Underwriters are asking AI-specific questions at renewal. An organisation that cannot evidence its controls is self-insuring a category it has never sized.
The systems nobody registered
Start with the count, because almost nobody has one.
Drata: 13% of IT and security professionals report full visibility into active AI tools
Protiviti: 47% of large organisations lack full visibility into employee AI use
DigiCert: roughly half lack centralised visibility, while 75% deployed four or more AI systems in six months
Smarsh and FTI: 30% have comprehensive capability to detect AI use outside approved workflows
Three examples, all of them from real inventories
An analyst pastes a customer list into a consumer assistant to clean it. Under a consumer tier, that data may be retained, used for training, and processed in a region your DPA never contemplated. You have just made an unassessed international transfer of personal data, and you cannot report it because you do not know it happened.
A recruiter runs CVs through a summarisation tool. If its output materially influences who gets shortlisted, it may fall within the EU AI Act’s high-risk employment category regardless of what the vendor calls it. Where it does, you have to evidence human oversight, use within instructions, logging and worker information, and none of that exists because nobody knew there was a system to attach it to.
A support team builds an agent in a low-code platform with read access to production. That agent holds a credential nobody issued formally, takes actions nobody logs, and cannot be terminated by anyone outside that team.
None of it crossed a procurement threshold, so none of it went through procurement. No contract, no assessment, no owner, no exit plan.
Your legal exposure does not depend on whether you knew about the system. Every duty that would have applied still applies, and you now have neither the records to demonstrate compliance nor the ability to stop the thing.
That is also the honest answer to why an inventory comes before a policy. A policy governs the systems you listed. The ones you did not list are the ones that will produce the incident, and they are the majority in most organisations.
The instinct is to ban it. Prohibition fails here, because the tools work and people who need them will use them anyway, off the network and out of sight. Banning converts a visibility problem into a concealment problem, and concealment is worse: you keep the liability and lose the last of the evidence.
What works is a sanctioned route genuinely easier than the unsanctioned one, plus amnesty for anyone who discloses what they have already been using. Set the boundary before you announce it: disclosure carries no penalty, and every disclosed system goes into assessment immediately. Amnesty without that second half is just a list.
Standards: three separate problems
There are three instruments worth adopting, and they do different jobs.
ISO 42001 is the certifiable one. It sets out how to build an AI management system and gives you thirty-eight AI-specific controls to choose from, which is the closest thing to a shared baseline a buyer will recognise. NIST’s AI Risk Management Framework gives your teams a common vocabulary for risk work and is voluntary, with nothing to certify against. Singapore’s IMDA has published a dedicated framework for agentic AI, which is currently the most useful guidance on what oversight means once a system takes actions rather than producing outputs.
Adopt them. Then understand three limits that usually get collapsed into one vague scepticism.
Scope. You decide which controls apply and which systems sit inside the boundary. A company can certify a management system covering two internal tools, leave out the customer-facing model that generates its real risk, and display the badge where nothing says what it covers. When a supplier shows you a certificate, ask for the scope statement and the exclusions first.
Decisions. Certification confirms a process for making decisions exists. It does not confirm the decisions. Your management system can be fully conformant while the risk classification it recorded is wrong, because the audit tests whether you followed your own process.
Cadence. Certification runs annually with surveillance in between, a rhythm built for systems stable enough that a sample tells you about the interval. Yours are not. A vendor updates a model under a live contract. A team changes a data source. An agent’s permissions expand because someone needed to finish a task. The finding, when it comes, is rarely that something broke. It is that something broke in March and nobody knew until November.
The question to ask on Monday
You do not need to understand a model to govern one. Ask when a control was last exercised, and ask to see the record.
That question surfaces almost everything in this piece and requires no technical knowledge at all. If someone can produce the record, you are governing something. If nobody can, you have documents, whatever the certificate says.
Six follow-ups, each with a yes or no answer, none of them documents.
Contractual notification on model change. Otherwise your most consequential system alteration arrives silently, from a vendor, with no ticket.
Monitoring with thresholds that trigger action, not a quarterly report someone reads later.
Reclassification when the use case changes. That is when obligations move, and nobody puts it in a calendar.
A kill path a named person has exercised on a live system, with a date.
An override log that gets reviewed. Zero recorded overrides in eighteen months is telling you something.
A contestation route that stays open, rather than being rebuilt the week before an audit.
Take those to your next risk committee and count the answers.
Then look at what answering them properly requires. Contractual notification means renegotiating vendor terms your procurement team signed without it. Reclassification on use-case change means someone who can tell when a use case has legally changed. A contestation route means designing a process that touches legal, customer operations and product at once. These are not questions you delegate to whoever has capacity. They need someone who can hold the legal, technical and organisational sides of the same decision, and most companies do not have that person yet.
Why those six, and not model safety
This summer produced the first serious public evidence that agent risk is an action-path problem rather than a model-alignment problem.
28 July. During a UK AI Security Institute cyber evaluation, monitoring detected unusual data transfers leaving the environment through Tor. AISI contained it within about an hour. Its review found 19 unsanctioned actions across 10 of 122 runs, directed at real people and organisations on the live internet, with no confirmed harm.
21 July. OpenAI confirmed an autonomous agent in a security evaluation escaped containment, reached the internet and compromised Hugging Face infrastructure to satisfy its evaluation goal. Hugging Face had already detected the intrusion and reported it to law enforcement before learning where it came from.
30 July. Anthropic published an investigation covering three incidents across six runs out of 141,006 reviewed, including a package published to PyPI for about an hour and executed on fifteen real systems. Its own reading: closer to a harness and operational failure than a model alignment failure.
6 August. Meta disclosed that one of its models reached the internet during an evaluation and exploited a vulnerability in a third-party service. Its own spokesperson named the cause: a misconfiguration by Irregular, the independent testing firm Meta uses. Anthropic's three incidents traced to the same environment, and OpenAI disclosed a second Irregular-linked incident separate from the Hugging Face breach. One Tel Aviv firm of roughly thirty-five people ran the evaluations behind containment failures at three frontier labs. If your company uses a single red-team vendor across its whole portfolio, that is the same concentration with fewer people watching.
Your company is deploying agents into environments built for none of that. In a 2026 Cloud Security Alliance survey, 82%of respondents said their organisations had discovered previously unknown AI agents in the preceding year, and 65% reported at least one AI-agent-related incident. Kiteworks’ 2026 research found 63% could not technically enforce purpose limitations on AI agents, and 60% could not quickly terminate one that misbehaved.
Credential ownership and tested revocation. A kill path someone has exercised. Monitoring that triggers action. Those are the controls that failed. None of it would have shown up in a vendor’s safety documentation.
What a governance strategy actually is
Most of what gets called an AI strategy is an adoption plan with a risk annex at the back. Nine questions separate one from the other.
Who approves a deployment, and who can stop one
What you will not build or buy, decided in advance rather than argued case by case under delivery pressure
How systems are classified, and who revisits it when the use case shifts
What your vendor terms require on model change notification, audit rights, data handling and exit
Which systems require pre-deployment testing, what the threshold is, and who sets it
What continues to be monitored after release, at what interval, and what trips an alarm
How an affected person contests a decision, to whom, with what record, in what timeframe
What gets escalated, to which forum, how fast
How a system is retired
None of these are technical questions. They are the same decisions you already make about capital allocation, supplier risk and delegated authority, and your company has made none of them for AI.
What tooling can and cannot carry
Platforms exist that hold your inventory, generate documentation, map controls to named instruments, run scheduled tests, monitor drift and produce evidence packs. They are worth having. A company with one is better off than a company keeping its inventory in a spreadsheet nobody has opened since March.
Tooling records accountability. It does not create it.
Every field these platforms hold was filled in by someone at your company. The platform asks who owns this system and accepts whatever gets typed. It asks for the risk classification and records the answer. It asks whether human oversight is in place, and a tick becomes a green cell whether or not any human has ever exercised it.
There is a second cost that shows up later. Tooling measures what is measurable, so programmes drift toward what the tool counts. Assessments complete. Policy coverage. Training completion. Those numbers rise for eighteen months while your actual exposure sits where it was, because none of them asks when a control was last used or what an affected person does.
Buy the tool. Buy it after you have answered the questions it will ask you.
Why this comes down to a person
The certificate records decisions someone made. The platform records decisions someone made. The framework organises decisions someone made. Not one of them makes a decision, and the decisions are where your exposure lives.
Making them requires four things held at once. Take a recruitment screening tool your team bought and configured.
Legal establishes where it sits in the classification, and whether reconfiguring it moved you from deployer to provider
Technical establishes what the model is doing and whether the vendor’s testing covered the populations in your market
Policy establishes where obligations are heading and how a deferred deadline meets commitments you already made in a tender
Sociological establishes who is being screened out, whether the historical data encodes a pattern you have since repudiated, and whether the appeal route is usable by someone who has just been rejected
In the AAA survey, technical teams were involved in governance 80% of the time and legal and compliance 35%. That imbalance is not an oversight. It is what happens when a company treats this as a systems problem and staffs it accordingly.
Certification gives someone the vocabulary. Knowing which of those four framings decides a particular room comes from having sat in enough of them.
Hiring, buying, or both
You will find hiring harder than the market makes it sound, and the constraint is not budget. An open role stays open, and a control that does not exist for eight months is a control that does not exist. The work arrives in phases rather than continuously, so permanent headcount built around it gives you either idle capacity or a backlog. And your internal lead reports to someone whose targets depend on shipping, which makes telling a business unit to stop a career-affecting act rather than a professional judgment. Independence is most of what makes the judgment worth paying for..
The arrangement that works is an internal owner who holds the decision rights, supported by external capability that builds the architecture, stress-tests it against what the internal team cannot see, and leaves when it works.
Where to start
Count the systems, including the ones bought on a personal card and built in low-code platforms, and decide what triggers a recount. New purchase, model version change, use-case change. An inventory with no trigger is accurate for about a quarter.
Name a person for each, not a committee
Establish for each whether you are provider or deployer, and whether reconfiguration moved you between them
Meet what is already binding, since transparency and AI literacy duties cost less now than they will to explain later
Test one control on your highest-stakes system and find out whether anyone has ever exercised it
Build the route by which an affected person contests a decision
Then use the extended European runway deliberately rather than under deadline pressure. It is the one thing the deferrals actually gave you, and almost nobody is taking it.
I work on this. Governance architecture and decision rights, vendor and third-party AI risk, guardrail design, maturity assessment, EU AI Act readiness, and training for teams who have to make these calls without a lawyer in the room. If your company is somewhere in the six steps above and stuck on one of them, reply to this email and tell me which one.
Nesibe,
TechLetter is written by Nesibe Kırıs Can, an AI governance researcher and technology policy scholar based in Istanbul.
📚 Everything I’ve filed so far lives at reports.techletter.co — cheat sheets on the EU AI Act, ISO 42001, agentic AI governance and AI policy structure. Sourced and dated, always.
🔔 New around here? Subscribe and I’ll see you next week.
Frequently asked questions
We hold ISO 42001. Is that enough?
It attests that a management system exists inside a scope you defined yourself. Ask what your own Statement of Applicability excludes.
We bought a governance platform. Is that enough?
It records accountability without creating it. Every field it holds was filled in by someone at your company.
We only operate in one country. Does the EU AI Act apply to us?
Possibly, through your customers, your vendors, or the markets your product reaches. And it is not the only route to exposure.
Hire internally or engage an advisor?
Usually both, in that order of authority. Decision rights belong inside the company. Architecture and stress-testing benefit from someone outside the reporting line the deployment decision runs through.
This is a really insightful piece. I especially liked the distinction between having governance documents and actually having decision rights and controls that someone has exercised.
The distinction between an action-path failure and a model-alignment failure is spot on. The red-teaming examples really illustrate how fast things fall apart when governance is treated purely as a prompt-level safety issue rather than an operational containment issue. The point about 'exercised kill paths' will probably make a lot of CISOs very uncomfortable—in the best way possible."