BlogAI Governance
AI Governance16 min read read

The EU AI Act Hits in 90 Days and 88% of Your AI Systems Are Invisible to Compliance

67% of your employees are already using AI tools. Only 18% of organizations have policies governing that use. And fewer than 12% of enterprise AI applications are even visible to IT. In 90 days, the EU AI Act starts enforcing fines up to 7% of global turnover — not EU revenue, global revenue. Here is the compliance checklist your CISO needs this week, not next quarter.

By Richard Ewing·
Share:

Your Compliance Team Cannot Govern AI Systems They Cannot See

88% of your enterprise AI systems are invisible to IT and security. Your employees are running ChatGPT, Claude, Copilot, and dozens of smaller tools on personal accounts, browser extensions, and API keys buried in Slack channels — processing customer data, generating production code, making decisions that affect EU citizens. And in 90 days, every one of those invisible systems becomes a 7%-of-global-turnover liability.

On August 2, 2026, the EU AI Act enters its next major enforcement phase. The penalty structure is designed to be existential: fines up to 7% of global annual turnover. Not EU revenue. Not European subsidiary revenue. Global turnover. A company doing $1 billion in annual revenue faces $70 million per violation. And the Act does not just regulate AI products you sell — it regulates AI systems you use internally, including the ones your IT team does not know exist.

67% of employees use AI tools at work. Only 18% of organizations have governance policies. That 49-point gap between adoption and governance is the single largest compliance exposure in enterprise technology today. This is the 90-day checklist to close it — not a white paper, not a webinar. A checklist.


The Shadow AI Problem You Cannot Ignore

Before you can comply with the EU AI Act, you need to know what AI systems you are running. Most organizations cannot answer this question.

67% of employees use AI tools at work. Only 18% of organizations have policies governing that use.

That gap — 67% adoption, 18% governance — is the single largest compliance risk for any enterprise subject to the EU AI Act. Your employees are using ChatGPT, Claude, Gemini, Copilot, Midjourney, and dozens of smaller tools to process company data, generate customer communications, analyze financial documents, and write code that ships to production.

And IT does not know about most of it. Research indicates that fewer than 12% of AI applications in the enterprise are visible to IT and security teams. The other 88% exist in the shadow — personal accounts, browser extensions, mobile apps, and API keys buried in engineering team Slack channels.

The EU AI Act does not care whether you knew about the AI system. If it processes data involving EU citizens and your organization deployed or authorized its use, you are liable.

Use the Shadow AI Assessment to inventory your organization's actual AI footprint before attempting any compliance work.


Phase 1: Discovery and Classification (Days 1-30)

Week 1-2: AI System Inventory

You cannot govern what you cannot see. The first two weeks are dedicated to building a complete inventory of every AI system in your organization:

  1. Enterprise tool audit — Catalog every AI-enabled tool with a corporate license: Copilot, ChatGPT Enterprise, Salesforce Einstein, ServiceNow AI, etc.
  2. Shadow AI sweep — Use network traffic analysis, SSO logs, and expense reports to identify AI tools being used without IT approval. The Shadow AI Assessment provides a structured methodology for this discovery.
  3. Embedded AI identification — Many enterprise tools have added AI features without explicit notification. Audit your existing SaaS stack for AI capabilities that may have been enabled by default.
  4. Custom AI systems — Inventory all internally-built models, fine-tuned systems, RAG pipelines, and agent architectures. Include proof-of-concepts that are "not in production" but are processing real data.
  5. Third-party AI in supply chain — Identify vendors who use AI to process your data. This includes SaaS providers, outsourcing partners, and managed service providers.

Week 3-4: Risk Classification

The EU AI Act categorizes AI systems into four risk tiers. Each system in your inventory must be classified:

  • Unacceptable Risk — Banned outright: social scoring, real-time biometric surveillance (with limited exceptions), manipulative AI, exploitation of vulnerabilities.
  • High Risk — Permitted with strict requirements: AI in hiring, credit scoring, insurance, education, law enforcement, critical infrastructure, and safety components. Requires conformity assessment, ongoing monitoring, transparency, and human oversight.
  • Limited Risk — Transparency obligations only: chatbots must disclose they are AI, deepfakes must be labeled, AI-generated content must be identifiable.
  • Minimal Risk — No specific requirements, but voluntary codes of conduct encouraged.

Critical nuance: The classification depends not on the technology but on the use case. The same LLM is "minimal risk" when summarizing meeting notes but "high risk" when evaluating employee performance or screening resumes.


Phase 2: Gap Analysis and Remediation Planning (Days 31-60)

The Governance Gap

For each high-risk AI system, the Act requires:

  1. Risk management system — Continuous identification, analysis, estimation, and evaluation of risks
  2. Data governance — Training, validation, and testing data must meet quality criteria
  3. Technical documentation — Comprehensive documentation of the system's design, development, and capabilities
  4. Record-keeping — Automatic logging of system operations for traceability
  5. Transparency — Clear information about the system's capabilities, limitations, and intended use
  6. Human oversight — Systems must be designed to allow effective human oversight
  7. Accuracy, resilience, and cybersecurity — Systems must meet appropriate levels of all three

Most organizations will discover that zero of their AI systems meet all seven requirements. This is normal. The goal in Phase 2 is to quantify the gap and build a remediation plan — not to achieve compliance.

The Hallucination Liability

Here is a statistic that should reshape your risk calculus: 47% of enterprise leaders have made business decisions based on hallucinated AI content. Nearly half of executives have acted on information that an AI system fabricated — and they did not know it was fabricated.

Under the EU AI Act's transparency and accuracy requirements, if a high-risk AI system produces hallucinated outputs that lead to decisions affecting EU citizens, the deploying organization faces liability. "The AI hallucinated" is not a defense. It is an admission of non-compliance with accuracy requirements.

The Insurance Wake-Up Call

Insurance carriers are now conditioning coverage on documented AI governance. Cyber insurance, D&O insurance, and professional liability policies increasingly include AI governance questionnaires. Organizations without documented AI risk management, incident response procedures, and audit trails face:

  • Premium increases of 30-60%
  • Coverage exclusions for AI-related incidents
  • Policy non-renewal at the next cycle

This is not future speculation. Carriers are already underwriting based on AI governance posture. If your organization cannot produce AI governance documentation today, your insurance coverage may already contain exclusions you have not read.

The Breach Cost Multiplier

IBM's research confirms what risk officers suspected: data breaches involving AI systems cost an average of $670,000 MORE per breach than breaches without AI involvement. The increase comes from:

  • Greater data exposure surface (AI systems often have broad data access)
  • More complex forensic investigation (AI decision chains are harder to reconstruct)
  • Higher regulatory scrutiny (regulators are paying special attention to AI-related breaches)
  • Longer containment times (AI-related breaches take an average of 28 days longer to contain)

Phase 3: Implementation and Documentation (Days 61-90)

Week 9-10: Policy Deployment

  1. AI Acceptable Use Policy — Publish a company-wide policy defining what AI tools are approved, what data can be processed, and what use cases are prohibited.
  2. AI Risk Assessment Framework — Implement a process for evaluating new AI systems before deployment. Every new AI tool must go through risk classification before procurement or adoption.
  3. Incident Response Procedures — Define how AI-specific incidents (hallucinations, bias events, data leaks through AI tools) are detected, escalated, investigated, and reported.
  4. Human Oversight Protocols — For each high-risk system, document who provides oversight, how they exercise it, and what authority they have to override AI decisions.

Week 11-12: Technical Controls

  1. Logging and audit trails — Ensure every high-risk AI system generates comprehensive logs of inputs, outputs, and decision factors. These logs must be immutable and retained for the period specified by the Act.
  2. Access controls — Implement role-based access to AI systems with the same rigor as financial systems. No employee should have unrestricted access to high-risk AI capabilities.
  3. Output validation — Deploy automated validation of AI outputs against defined accuracy thresholds. For high-risk systems, outputs exceeding error thresholds must be routed to human review.
  4. Data governance controls — Ensure training data, prompt templates, and system configurations are version-controlled, documented, and auditable.

Week 12: Board and Executive Reporting

Prepare a board-ready AI governance report that includes:

  • Complete AI system inventory with risk classifications
  • Gap analysis results with remediation timeline
  • Policy documentation status
  • Technical control implementation status
  • Residual risk assessment
  • Insurance coverage implications
  • Budget requirements for ongoing compliance

The ERM Framework Problem

If you are planning to handle AI Act compliance by extending your existing Enterprise Risk Management (ERM) framework, stop. Traditional ERM frameworks cannot adequately handle AI risk because they are designed for deterministic systems with predictable failure modes.

AI risk is fundamentally different:

  • Probabilistic vs. deterministic — Traditional risk management assumes you can enumerate failure modes. AI systems fail in novel, unpredictable ways. A model that worked correctly yesterday may hallucinate today because of a subtle change in input distribution.
  • Continuous vs. periodic — Traditional risk assessments happen quarterly or annually. AI models can drift in days. By the time your quarterly review catches a problem, you may have months of non-compliant operations to remediate.
  • Emergent vs. designed — Traditional systems fail in ways that were foreseeable (even if not foreseen). AI systems exhibit emergent behaviors — capabilities and failure modes that were not present in training and cannot be predicted from the system's design.

You need an AI-specific risk framework that operates on continuous monitoring, probabilistic risk assessment, and automated drift detection — layered on top of your ERM, not shoehorned into it.


The 90-Day Checklist Summary

Days 1-30: Discovery

  • ☐ Complete AI system inventory (enterprise, shadow, embedded, custom, supply chain)
  • ☐ Classify each system by EU AI Act risk tier
  • ☐ Identify all systems processing EU citizen data
  • ☐ Map data flows for each AI system
  • ☐ Document current governance gaps per system

Days 31-60: Analysis and Planning

  • ☐ Complete gap analysis against Act requirements for each high-risk system
  • ☐ Assess hallucination exposure across decision-making AI
  • ☐ Review insurance policy AI exclusions and governance requirements
  • ☐ Build remediation roadmap with priorities and resource requirements
  • ☐ Identify systems that must be decommissioned or replaced

Days 61-90: Implementation

  • ☐ Publish AI Acceptable Use Policy
  • ☐ Deploy AI Risk Assessment Framework for new tool procurement
  • ☐ Implement incident response procedures for AI-specific events
  • ☐ Enable comprehensive logging for all high-risk systems
  • ☐ Deploy output validation for high-risk AI systems
  • ☐ Deliver board-ready AI governance report
  • ☐ Submit conformity assessment documentation (where required)

What Happens If You Do Nothing

The EU AI Act is not GDPR 2.0 where enforcement was slow and initial fines were small. The Commission has been explicit: enforcement will begin at scale in August 2026. The fines are designed to be material — 7% of global turnover makes this the most punitive technology regulation in history.

But fines are not even the primary risk. The real risks are:

  • Insurance coverage gaps — Carriers are already excluding AI incidents from policies without documented governance.
  • Customer trust erosion — Enterprise customers are increasingly requiring AI governance documentation as part of vendor due diligence. If you cannot produce it, you lose deals.
  • Talent flight — Engineers and compliance professionals do not want to work at organizations that ignore regulatory requirements. The liability exposure falls on them personally.
  • Board liability — Directors have fiduciary duties to ensure regulatory compliance. Documented awareness without action creates personal liability.

Start today. Run the Shadow AI Assessment to discover your actual AI footprint. Schedule an advisory session to build your 90-day compliance roadmap with expert guidance.

The regulation does not care whether you knew about the AI system — it cares whether you governed it.

Like this analysis?

Get the weekly engineering economics briefing — one email, every Monday.

Subscribe Free →

More in AI Governance

Canonical Frameworks

Innovation Tax

The Innovation Tax is the hidden cost of maintenance work that gets reported as innovation investment. It is OpEx masquerading as R&D investment, causing organizations to dramatically overestimate their effective engineering velocity and R&D productivity. Here's how it works: A VP of Engineering reports to the CEO that "65% of engineering time is spent on new features." The actual breakdown, when forensically audited, reveals that only 23% of engineering time produces genuine new capabilities. The remaining 42% is maintenance work embedded within feature sprints — bug fixes bundled into feature stories, infrastructure upgrades coded as dependencies, and refactoring disguised as feature prerequisites. This 42-point gap between reported and actual innovation investment is the Innovation Tax. It's not fraud — it's systematic self-deception enabled by the way agile teams organize work. When a sprint contains 10 stories and 4 of them are technical debt cleanup dressed as "tech stories" within a feature epic, the team genuinely believes they're spending 100% on features. The Innovation Tax is insidious because it compounds. As the maintenance burden grows quarter-over-quarter, the tax increases. But because teams don't measure it, CFOs and boards continue to believe R&D spending is generating proportional innovation output. By the time the gap becomes visible (missed deadlines, slow feature delivery, competitive lag), the organization is often approaching the Technical Insolvency Date. Benchmarks from Richard Ewing's audits show that most engineering organizations have an Innovation Tax between 30-50%. Organizations with Innovation Tax above 40% are in dangerous territory. Above 70% is terminal — the organization is approaching technical insolvency within 4-6 quarters.

Read Definition →

Kill Switch Protocol

The Kill Switch Protocol is a structured framework for identifying and deprecating "Zombie Features" — code that requires ongoing maintenance but generates zero incremental business value. Most software organizations have a dangerous bias: they add features but never remove them. Product teams celebrate launches. Nobody celebrates deletions. Over time, this creates what Richard Ewing calls "feature gravity" — a constantly growing codebase where 40-60% of the code serves no active users and generates no measurable revenue, yet still consumes engineering maintenance hours. Zombie features come in several varieties: - **Ghost Features**: features that were built, launched, and never adopted. They sit in the codebase, requiring maintenance, but have near-zero usage. - **Legacy Bridges**: compatibility layers, deprecated API versions, and backward-compatible code paths that serve a tiny percentage of users but add complexity to every future change. - **Vanity Features**: features built because a senior stakeholder wanted them, not because users needed them. Often protected by organizational politics rather than business merit. - **Abandoned Experiments**: A/B test variants that were never cleaned up, prototypes that became permanent, and "temporary" solutions that became load-bearing. The Kill Switch Protocol provides a systematic approach to identification, evaluation, and deprecation: 1. **Identify**: Flag features with less than 5% of peak usage, zero revenue attribution, or maintenance cost exceeding 10% of the feature's value contribution. 2. **Quantify**: Calculate the total cost of keeping each zombie alive (maintenance hours × fully-loaded engineer cost × opportunity cost multiplier). 3. **Assess Risk**: Evaluate deprecation risk — what breaks if this feature is removed? What customers are affected? 4. **Sunset Timeline**: Create a communication plan and graduated deprecation (warning → deprecation notice → feature flag → removal). 5. **Execute**: Remove the code with rollback capability. Monitor for unexpected breakage. The typical Kill Switch audit reveals that 30-50% of maintenance burden comes from zombie features. Removing them frees up 15-25% of engineering capacity for actual innovation.

Read Definition →

Ontology Pathways

Explore the structurally connected systems, failures, and controls related to this concept.

Exogram Routing

System Control Plane Mappings

Enforced by: boundary-control

This failure mode is structurally blocked at runtime by the Exogram Operating System. The specified admissibility routing layer intercepts execution before probabilistic variance can affect the deterministic core.

📊

Richard Ewing

The AI Economist — Quantifying engineering economics for technology leaders, PE firms, and boards.

Want to apply this to your organization?

Run a free diagnostic first. If the numbers concern you, book a session to build a remediation plan.

Richard Ewing — AI Economist & Capital Auditor