Someone at your company got the AI mandate. Maybe it was you. The CEO said we need to be doing AI, looked at the person closest to the stack, and asked them to figure it out—no budget line for compliance. No playbook. Just a deadline that's already making them anxious.
A few weeks later, Claude is triaging recruiting applications before they hit the ATS. Or scoring inbound leads before they land in HubSpot. Or summarizing support tickets before a human reads them.
Nobody called this an "AI product." It's an internal workflow, wired together to save someone's Tuesday. Which is exactly why almost nobody checks it against the EU AI Act.
Here's the part that surprises most of the mandate carriers we talk to: the Act doesn't care whether you're shipping a copilot feature to paying customers or duct-taping a Claude skill into your own hiring pipeline. If the workflow touches employment, creditworthiness, or another Annex III category, the same obligations apply either way, regardless of price tag.
One thing changed since we first published this piece: the deadline moved, and as of today, it's official. The Digital Omnibus on AI was published in the EU's Official Journal on July 24, 2026 (Regulation confirming the amendment), pushing standalone Annex III high-risk obligations from August 2, 2026 to December 2, 2027. Article 50 transparency rules stay on the original schedule. The Article 4 AI literacy duty also keeps its original date, though its substance was softened from a guaranteed literacy level to a "support the development of" standard. None of this touched the fines.
Key Takeaways
EU AI Act high-risk rules apply to internal AI workflows (HR screening, credit decisions, customer eligibility calls) exactly as much as to a product you sell. Annex III is defined by use case, not by whether you have paying customers.
The deadline moved, officially: the Digital Omnibus on AI, published in the Official Journal on July 24, 2026, shifts standalone Annex III high-risk obligations from August 2, 2026 to December 2, 2027. Article 50 keeps its original date; Article 4 keeps its date but was softened in substance.
Penalties still come in tiers: up to €35M or 7% of global turnover for prohibited practices, up to €15M or 3% of turnover for breaches of the high-risk provider/deployer obligations (Article 99, EU AI Act).
Most Annex III systems, recruiting screening and credit scoring included, use internal self-assessment, not a notified-body review. That's not relief. Nobody outside your team is checking your blind spots before a regulator does.
The fix isn't a bigger GRC tool. It's four habits: Delegation, Description, Discernment, and Diligence, the same habits that make any AI workflow trustworthy, not just a compliant one.
We didn't invent those four habits. They come from Anthropic's AI Fluency framework, and they're the spine of every implementation we build. Below are the seven traps we keep finding in internal AI workflows at growing companies, organized around the D each one is really about. Extra runway doesn't fix any of them. It just changes when you'll wish you had it.
The seven traps, at a glance:
Delegation: treating every workflow as equally low-risk, regardless of what it actually touches.
Description: documentation that describes last month's system, not today's.
Discernment (bias): trusting the model provider's safety filter to catch problems your own prompt introduces.
Discernment (tooling): treating ordinary DevOps testing as a quality management system.
Diligence (vendor chain): no independent record of what you sent a provider and what came back.
Diligence (self-assessment): assuming a notified body is checking your work when, for most workflows, nobody is.
Diligence (scattered logs): reconstructing a single decision across five different dashboards.
Delegation: What Actually Needs Governance Before You Build It?
Delegation means thoughtfully deciding what work to hand to AI and what stays with a human, including which workflows carry enough risk to need a governance layer before anyone touches them. Annex III of the EU AI Act defines that risk by use case, not by who built the system (Annex III, EU AI Act), so a generic internal tool can cross into high-risk territory the moment someone repurposes it for hiring or credit decisions.
The trap: You built a "summarize and route" skill for your ops team. Legal signs off because it "just summarizes text." Then someone on the recruiting side starts feeding it resumes to pre-screen candidates before a human looks at them. In a single afternoon, your low-risk internal tool became a high-risk system under Annex III, and nobody updated the risk assessment because nobody knew the use case had changed.
If every workflow gets treated the same regardless of what it actually touches, you end up choosing between applying heavy governance to everything (slow, expensive, kills adoption) or missing the one workflow that actually needed it (the one a regulator or a rejected candidate asks about).
The fix: Tag risk at the workflow level, not the tool level. Every Claude skill or connector we build carries a risk_profile flag set at creation and re-checked whenever its scope changes. A workflow flagged high_risk (recruiting, credit, access-to-services) routes through stricter logging and a mandatory human-review gate before output reaches anyone. The question to ask your own stack this week: can you name every internal workflow that touches an Annex III category, in one sitting, without opening five tools first?
Description: Writing Down What the System Actually Does, and Keeping It Current
Description is communicating clearly and precisely about what a system does. Applied to compliance, that means your documentation has to describe the system as it exists today, not as it existed the week you wrote the PDF. Article 11 of the EU AI Act requires technical documentation for high-risk systems to reflect the system as currently deployed (Article 11, EU AI Act), so documentation describing a deprecated model version isn't just stale. It's non-compliant.
The trap: Someone spends a week producing a beautiful technical write-up: the model version, the retrieval pipeline, the guardrails. Two weeks later, the model provider deprecates that version, and your team ships a hotfix. The document is now describing a system that no longer exists. Under the AI Act, outdated documentation for a high-risk system isn't sloppy. It's non-compliant.
The fix: Treat documentation as code, not as a deliverable. Every deployment should generate a small structured artifact (model ID, system prompt hash, temperature, retrieval source version) versioned alongside the code that produced it. If your compliance documentation doesn't update itself every time you ship, it's already lying to you.
Discernment: Judging the Output, Not Just Trusting the Vendor's Safety Filter
Discernment is evaluating AI outputs critically: knowing when to trust them, when to question them, and when to override them. Article 17 requires high-risk AI providers to maintain a quality management system that explicitly covers risk management and incident reporting (Article 17, EU AI Act), a bar that ordinary DevOps testing and CI/CD pipelines don't clear on their own. Two traps live here, and they're really the same failure at different layers.
The trap (bias): You rely on your model provider's built-in safety filters and assume that makes your application safe by extension. It doesn't. The Act regulates you as the system provider, not just the underlying model. If you wrap a foundation model into "rank these applicants" or "flag this transaction," you own the bias your prompt structure and retrieval logic introduce. The provider's filter was never built to catch that your specific prompt quietly downranks non-native English speakers.
The trap (tooling): You have a strong DevOps culture: unit tests, integration tests, alerting. And you tell an auditor your Quality Management System is your CI/CD pipeline. Article 17 requires a QMS that explicitly addresses risk management and incident reporting. A failing unit test is a code problem. A model that hallucinates advice on a customer's eligibility is a risk problem. Standard DevOps tooling doesn't know the difference, which means you have no audit trail of risk decisions at all.
The fix: Build a small "golden dataset" of edge cases designed to surface bias, and run it against any prompt change before it reaches production. Layer a lightweight risk registry on top of your existing issue tracker: tag incidents risk-impact, and link every one to the specific model version and prompt version involved. You don't need a new tool. You need a habit of asking "is this a bug, or is this a risk decision?" every time something goes wrong.
Diligence: What Audit Trail Do You Need Before Someone Asks For It?
Diligence is understanding what happens to data, what leaves the building, and what the governance layer actually looks like, not as an afterthought but as a first-class part of the build. Three traps live here, and together they're the biggest gap we see.
The trap (vendor chain): Your architecture depends on a chain of providers: cloud hosting, a vector database, a model API. Article 25 covers the AI value chain: if one of those providers has an outage or changes terms and your system fails as a result, you're the one facing the regulator, not them. Pointing upstream doesn't work if you have no independent record of what you sent and what came back.
The trap (self-assessment): You hear "high-risk system" and assume a government inspector has to sign off before you can use it. For most Annex III workflows, including the recruiting-screening and credit-scoring examples above, they don't. Conformity assessment is internal self-assessment under Annex VI. Notified-body review only kicks in for a narrow slice: remote biometric identification, or AI embedded in a product that already needs third-party certification, like a medical device or a piece of machinery. If your workflow isn't in that slice, nobody outside your team is checking your work before it ships.
The fix: Treat self-assessment like an internal audit built to survive being read by someone who isn't you. Document the classification decision itself, not just the system. "We didn't think anyone would check" is not an answer that ages well in front of a market surveillance authority. The few systems that do need a notified body face their own bottleneck: as of March 2026, very few bodies were fully designated for AI-specific assessment (reporting on the notified-body gap), so budget for a long queue if you're in that group.
The trap (scattered logs): A regulator, or a candidate who was rejected, asks you to reconstruct exactly why the system decided what it decided on a specific date. You start checking five different dashboards: hosting logs, the database, the vector store, the model provider's console, just to stitch together one decision. That's not just slow. Article 12 requires automatic, unified record-keeping. Manual archaeology across five systems is itself the compliance failure.
The fix: Log independently of your providers: keep your own record of every request and response, not a reliance on logs you don't control. Centralize the full "decision DNA" of every AI transaction (input, retrieved context, system prompt, model parameters, output, latency, cost), bound together by one trace ID.
We've written before about what happens when your architecture leans on a single provider for this, and about treating compliance like technical debt you pay down in sprints instead of all at once. The same logging gap shows up whenever an AI system fails silently in front of a user,r and nobody can reconstruct why.
This is the part I've actually built before, not just read about. Before PromptMetrics existed in its current form, we built an LLM observability tool that logged exactly this kind of decision trail, and eventually open-sourced it.
The lesson that stuck: centralized logging isn't a compliance checkbox. It's the difference between debugging a hallucination in minutes versus losing an afternoon to archaeology across five dashboards. We build that same audit-trail layer into every implementation we ship now, not as a separate product, but as a first-class part of the build itself.
Quick Reference: Who Requires What
Article | What It Requires | Who It Applies To | Fine for Non-Compliance |
|---|---|---|---|
Technical documentation reflecting the system as currently deployed | Providers of high-risk AI systems | Up to €15M or 3% of turnover | |
Automatic, unified record-keeping (logs) | Providers of high-risk AI systems | Up to €15M or 3% of turnover | |
Quality management system covering risk and incidents | Providers of high-risk AI systems | Up to €15M or 3% of turnover | |
Responsibility along the AI value chain | Providers, importers, distributors, deployers | Up to €15M or 3% of turnover | |
Sets the fine tiers themselves | All operators | €35M or 7% (prohibited practices), €15M or 3% (high-risk) |
Governance as Care: Isn't This Just More Paperwork?
The reframe that actually matters, past the fines and the audit dates: every approval gate, every human-review step, every piece of this that feels like paperwork is the same requirement as "keep a human in charge of the decision." Article 12 traceability and the human is still in charge here are the same idea, described two different ways.
We build this because we believe the point of AI is to make work more human, not less, not because a regulator is watching. If you fix the logging (the Diligence habit above), you don't just satisfy an auditor. You gain the visibility to catch a bad output before it reaches a candidate, a customer, or a regulator asking why.
FAQ
Does the EU AI Act apply to AI tools we only use internally, never sell to customers?
Yes. Annex III high-risk categories (employment, creditworthiness, access to essential services, among others) are defined by what the system does, not by whether it's sold externally. An internal recruiting-screening workflow carries the same obligations as a commercial one.
When do EU AI Act high-risk obligations actually take effect now?
December 2, 2027 for standalone Annex III systems, not August 2, 2026. The Digital Omnibus on AI, which delays the original date, was published in the EU's Official Journal on July 24, 2026 (EUR-Lex), so this is settled, not proposed. Article 50 transparency obligations stay on the original timeline. The Article 4 AI literacy duty also keeps its original date, though its substance was softened. Treat December 2027 as the planning baseline, not an excuse to wait.
What's the actual fine for an EU AI Act violation?
It depends on the violation type. Prohibited AI practices under Article 5 carry fines up to €35M or 7% of global turnover, whichever is higher. Breaches of the provider and deployer obligations that come with running a high-risk system carry fines up to €15M or 3% of turnover (Article 99). SMEs face the lower of the two figures, not the higher.
What does Article 12 record-keeping actually require me to log?
Automatic, unified traceability of AI-driven decisions: enough that you can reconstruct why a specific output happened on a specific date without manually cross-referencing multiple systems. In practice: input, retrieved context, system prompt, model parameters, output, and a trace ID binding them together.
Do we need a notified body for our internal AI workflow?
Probably not. Most Annex III high-risk systems, recruiting screening and credit scoring included, use internal self-assessment under Annex VI. Notified-body review is required only for remote biometric identification systems and AI embedded in products that already need third-party certification. If you're in that narrow group, plan for a long queue: very few bodies were fully designated for AI-specific assessment as of March 2026 (reporting).
We haven't started. What's the first thing to do this quarter?
Audit your logging first. It's the trap with the widest blast radius and the one every other fix depends on. Then map which internal workflows touch an Annex III category, and confirm whether each one is in the self-assess majority or the notified-body minority. The extra runway doesn't mean waiting. It means fewer of these decisions get made under deadline panic.
Where we are, honestly: we're building this exact audit-trail and human-review layer into every implementation we ship right now, starting with our first customers. No case study page yet. If you want to be one of the first, you get our full attention and a price that reflects you going first.
If you want a second set of eyes on whether your current internal AI workflows would survive an Article 12 request, that's a Figure Out What to Build conversation, the free one where we map what needs governance before you build anything else. Not a sales call. Not a demo.
