EU AI Act Compliance for 250–1,000-Employee Companies: The Mid-Market Operating Model

Somebody at your company — payroll between 250 and 1,000 — just opened Google and typed “how do companies ensure AI compliance and data security?”. It is probably the head of IT, the GC, or a procurement lead who got an EU AI Act question from a customer and has thirty days to answer. The mid-market is the segment AI compliance content forgot. Enterprise gets serviced by the Big Four with a six-figure engagement and a 12-FTE GRC team. Startups get serviced by templated tools and a one-page acceptable-use policy. The 250-to-1,000-employee company gets neither: it has the regulatory exposure of an enterprise and the headcount of a startup.

This is the AI compliance operating model for that bracket. Not a checklist — a way to run it with two people, a register, a risk matrix, and a vendor questionnaire that fits on one page. Calibrated for a 2-to-3-person compliance team operating against the EU AI Act (Regulation 2024/1689), with high-risk obligations becoming enforceable on August 2, 2026. Calibrated for a budget that does not include hiring a Chief AI Officer.

Why mid-market needs its own model (and why the enterprise template will sink you)

The temptation in a 600-person company is to ask the GRC consultant for the deck they sold to a Fortune 500 and shrink it. That fails for three structural reasons.

First, the enterprise template assumes a dedicated AI governance function, typically 8–15 FTEs split across legal, security, data, and ethics. A 600-person company has, at best, two people who can credibly own AI risk: a legal/compliance lead and a security/IT lead. Anything that requires a third pillar dies on the org chart.

Second, the enterprise template scopes “AI system” broadly — every model, every pipeline, every internal experiment. A mid-market company that tries to inventory at that resolution will spend six months building the register before reviewing a single risk. The right resolution is the system of record: every commercial AI product the company has purchased or built that touches customer data, employee data, or a regulated decision.

Third, the enterprise template treats “we only use ChatGPT and Copilot” as a separate category requiring a separate workstream. It is not. The deployer obligations of Article 26 of the AI Act apply identically to a company that fine-tuned its own model and a company that bought ChatGPT Enterprise. The AI Act’s 2026 milestones make no distinction based on whether you trained the model or rented it — the company that puts a system into use is the deployer, full stop.

The 250-to-1,000-employee company needs a model designed for two people, a system-of-record-level inventory, and no distinction between “we built it” and “we bought it” — both make you the deployer.

The 2-person AI council: governance without a PMO

The single artifact that determines whether AI compliance becomes operational or remains a slide deck is the AI council. The enterprise template specifies eight roles; the mid-market version is two people with explicit charters and a 90-minute weekly meeting.

• Council seat 1 — Compliance lead. Profile: General Counsel, Head of Privacy, or Director of Compliance. Time commitment: 4 hours/week (one council meeting, one vendor review, two hours on documentation and incident triage). Authority: final say on whether a system goes into use, ban authority on systems that fail risk tiering, owner of the AI register.
• Council seat 2 — Technical lead. Profile: Head of IT, CISO, or Director of Engineering with security background. Time commitment: 4 hours/week. Authority: final say on architecture (on-prem, EU-region SaaS, public LLM with pseudonymisation), owner of vendor due diligence, owner of incident response.
• Optional seat 3 — Business sponsor (rotating). The function head requesting a new AI deployment attends the council meeting where their system is being reviewed. Not a permanent seat — a rotating one. This is what keeps the council from being seen as “the people who say no.”

That is the entire governance structure. No steering committee. No ethics board. No working groups. The two permanent seats own the operating model; the rotating sponsor brings business context; the CEO is the escalation path for the rare case the two seats deadlock. In our analysis of why most AI projects fail, the single most common pattern in mid-market deployments is over-governance — not under-governance.

The council’s weekly agenda fits on one page: (a) new system requests this week, (b) vendor reviews due, (c) incidents or near-misses, (d) regulatory updates, (e) next week’s scheduled risk-tier reviews. The output of each meeting is two artifacts: an updated register and a written decision log. If the meeting cannot produce both inside 90 minutes, the meeting is too crowded.

Two permanent seats (compliance + technical) plus a rotating business sponsor is the minimum viable governance organ; resist every consultant’s instinct to expand it.

The lightweight AI register and the 4-tier risk matrix

Article 26(6) of the AI Act requires deployers of high-risk systems to keep automatically generated logs “for a period appropriate to the intended purpose, of at least six months.” The enterprise interpretation is a full GRC platform integration. The mid-market interpretation is a spreadsheet plus the vendor’s own audit log export, reconciled monthly.

The register has nine columns — no more, no less:

• System name and vendor. The commercial product, not the underlying model. “ChatGPT Enterprise”, not “GPT-4o”.
• Business owner. Named individual, not a function. If nobody owns it, it does not go in the register — it gets shut down.
• Use case. One sentence. “Drafts first-pass marketing copy from product briefs.” Not a paragraph.
• Data classification. Public / Internal / Confidential / Restricted. The categories must match your existing data classification scheme — do not invent AI-specific ones.
• AI Act risk tier. Prohibited / High-risk / Limited-risk / Minimal-risk (the four tiers from Articles 5, 6, 50, and Recital 165).
• DPIA / FRIA status. Not started / In progress / Complete / N/A with date.
• Human oversight mechanism. One sentence describing who reviews what and when. If the answer is “the user reviews it,” that is not human oversight — that is hope.
• Vendor DPA reference. Contract section number, EU-region commitment, training-data-use prohibition, deletion timeline.
• Last reviewed. Date. Anything not reviewed in 12 months gets re-tiered automatically.

For the risk tier, the practical mid-market shortcut is the 4-tier matrix anchored in Article 6 and Annex III of the AI Act. Prohibited systems (social scoring, real-time biometric ID, emotion recognition in workplaces — Article 5) get banned outright. High-risk systems (HR/recruiting, credit scoring, education/access, critical infrastructure, law enforcement — Annex III) trigger the full DPIA+FRIA workflow and require Article 26(5) and 26(6) compliance. Limited-risk systems (chatbots, content generation visible to humans — Article 50) trigger transparency disclosures only. Minimal-risk systems (spam filters, video-game AI — the residual category) get logged but require no further action.

The 250-person company that tries to inventory every API call to OpenAI will burn out before completing the first quarter. The one that inventories systems-of-record and reviews them quarterly will be ready for an audit in twelve months.

For automation of the register’s recurring layer — log reconciliation, DPA expiration alerts, monthly evidence collection — a compliance and risk automation covers the operational burden so the council’s 4 hours/week stay focused on decisions, not paperwork. The detailed gap-assessment process is laid out in our 2026 compliance checklist.

A 9-column register at system-of-record resolution plus the 4-tier risk matrix from Articles 5/6/50 is enough — do not let a consultant talk you into a 47-field GRC schema.

The 7-question vendor DPIA/FRIA addendum

The most common procurement failure in 2026 will not be missing AI compliance — it will be discovering it after signing. The fix is a 7-question addendum that the procurement team attaches to every AI vendor evaluation, before contract negotiation begins. Copy-pastable, designed to be answered by the vendor in writing, designed to be reviewed by the AI council in under 30 minutes:

• 1. Is your system, as we intend to use it, classified as high-risk under Annex III of the EU AI Act? If yes, provide your Article 13 instructions for use and Article 14 human oversight measures. If no, explain why.
• 2. Where is our data processed and stored? List every region, including those used for failover and model training. Confirm EU-region availability if required.
• 3. Is our data used to train, fine-tune, or improve your models — ever, by default or by opt-in? If yes, describe the opt-out mechanism and confirm it is contractually binding.
• 4. What automatic usage logs do you generate, and how long do you retain them? Confirm they meet the 6-month minimum of Article 26(6) for high-risk systems.
• 5. What is your incident notification timeline for serious incidents under Article 73? Confirm in calendar days, not business days.
• 6. Do you provide a model card, datasheet, or transparency documentation sufficient for us to perform a FRIA under Article 27? If not, the FRIA gets done on the basis of the user being unable to assess fundamental rights impact — an immediate red flag.
• 7. What is your status as a General-Purpose AI provider under Article 53, and what GPAI obligations have you completed? For systems built on third-party foundation models, name the foundation model and its GPAI status.

Seven questions. One page. The vendor either answers them clearly, asks for clarification (acceptable), or stalls (instant red flag). The 30 days of procurement time saved versus a 47-question enterprise template is paid back the first time a vendor’s answer to question 3 is “yes, by default” and the deal dies before legal review. According to the ENISA Threat Landscape 2024 report, supply-chain and third-party data-exposure incidents remain among the top vectors for mid-market breaches — the vendor questionnaire is the cheapest mitigation available.

For companies whose procurement team wants outside help calibrating these questions to their specific stack, our honest answer on when you need a consulting firm for the AI Act walks through the decision criteria. Most mid-market companies do not.

A 7-question addendum applied before contract negotiation kills bad AI vendor deals at the cheapest possible moment — before legal hours, before security review, before integration cost.

The 30/60/90 implementation plan and the build/buy/outsource matrix

For a 2-to-3-person compliance team starting from zero, the 90 days that produce a defensible posture — not perfect, defensible — have three clean phases:

• Day 0–30 — Inventory and register. Two-week sprint of system discovery (survey every function head; reconcile against expense reports and SSO logs — the latter catches shadow AI). One-week sprint of register population (9 columns, system-of-record resolution). One-week sprint of risk-tier classification using the 4-tier matrix. Output: a populated register and a written list of every system flagged High-risk or Prohibited.
• Day 30–60 — Risk-tier and DPIA workflow. Two-week sprint of DPIA/FRIA completion for every High-risk system in the register. One-week sprint of human oversight mechanism documentation. One-week sprint of vendor DPA review and gap remediation. Output: every High-risk system either has a complete DPIA+FRIA or a scheduled date to be retired.
• Day 60–90 — Vendor reassessment and first internal report. Two-week sprint of applying the 7-question addendum to every existing AI vendor (not just new procurements — existing ones too). One-week sprint of building the recurring evidence workflow (monthly log reconciliation, quarterly register review). One-week sprint of producing the first quarterly internal compliance report to the executive team. Output: a defensible posture and a sustainable operating rhythm.

The build-vs-buy-vs-outsource matrix for the mid-market is the question most boards ask and the answer is rarely the same for every capability:

• Build internally: the AI register, the council’s decision log, the risk-tier classifications, the 7-question vendor addendum. These are the artifacts that encode your risk appetite — outsourcing them outsources judgement.
• Buy off-the-shelf: log-collection tooling, DPA template management, vendor-questionnaire workflow software. These are commoditised — do not build them.
• Outsource selectively: the initial gap assessment (one-time, 4–8 weeks of consulting), the FRIA template for the first one or two High-risk systems (knowledge transfer, then internal), specialist legal review of the customer-facing AI Act clause in your standard MSA (one-time legal spend).
• Never outsource: the council decision authority, the incident response chain, the customer-facing communication about your AI compliance posture. The moment a customer hears “our consultant said” instead of “our compliance team confirmed,” the deal momentum stops.

For the recurring evidence-collection layer — the part that consumes the most time and produces the least judgement — automated compliance reporting handles the monthly cadence so the council can spend its 90 minutes/week on decisions, not screenshot-collection. The detailed build-vs-buy framework for the reporting layer specifically is laid out in our analysis of the automated-reporting market.

The Verizon DBIR 2024 showed that mid-market companies (1,000–10,000 employees) were involved in over 38% of all breaches analysed — not because they are more vulnerable, but because they are the segment where security spend and threat exposure have diverged most. The AI Act adds a regulatory exposure on top. The operating model above closes the gap with two people, not twenty.

Ninety days, three phases, four capability decisions (build / buy / outsource selectively / never outsource) — the mid-market operating model is finite, sustainable, and defensible in front of the first customer audit of 2026.