EU AI Act readiness: know what AI you have, what obligations may apply, and what needs to change.
The EU AI Act became broadly applicable on 2 August 2026, and enforcement has started. Six days earlier, the high-risk obligations moved to December 2027. Both are true, which is why so much advice right now is confusing. We help you find the AI already running in your organization, work out which obligations may apply and to whom, and build governance into the way your teams already work.
Readiness, governance design and implementation. Not legal advice.
The high-risk chapter moved. Everything else did not.
On 27 July 2026, the Digital Omnibus on AI (Regulation (EU) 2026/1744) amended the AI Act, six days before the Act's main application date. It pushed back the high-risk obligations, and only those. Standalone high-risk systems (Annex III) now apply from 2 December 2027, and high-risk systems embedded in regulated products (Annex I) from 2 August 2028. Everything else stayed on schedule: on 2 August 2026 the rest of the Act became broadly applicable and enforcement began.
Prohibited practices and AI literacy, since 2 February 2025. General-purpose AI model rules, since 2 August 2025. Transparency obligations, registration and enforcement, from 2 August 2026.
A ninth prohibited practice covering AI-generated non-consensual sexual intimate imagery or child sexual abuse material. Plus a transitional deadline for marking synthetic content from certain generative systems already on the market before 2 August 2026.
The high-risk obligations: classification rules, risk management, data, documentation, logging, human oversight, accuracy, cybersecurity, and the obligations on providers and deployers.
"The EU delayed the AI Act" and "the high-risk chapter was deferred" are different statements. If your planning assumed everything landed on 2 August 2026, part of it has sixteen extra months and part of it is already overdue.
The expensive part of high-risk readiness is not writing documents. It is finding every AI system you have, working out what each one does, and keeping that record accurate as vendors ship new features. That work is unaffected by the deferral.
The biggest readiness gap is the AI nobody has written down.
You cannot assess obligations for AI you do not know exists. This is not a criticism of governance. It is a description of how AI arrived: through channels no central function controls.
The inventory is incomplete
AI shipped inside products you already owned, arrived with tools bought below procurement thresholds, and appeared as features in enterprise applications you govern well for everything else.
Roles are unclear
Your obligations depend on whether you are a provider or a deployer of a given system. Most organizations are both, in different places, sometimes without noticing when they crossed over.
Classification is inconsistent
Ask three people whether a use case is high risk and you get three answers, because they are classifying by product name or vendor rather than by what it does and who it affects.
Evidence is scattered
The rationale exists in emails, meetings and spreadsheets. What does not exist is a record that could be produced on request.
The fastest-growing source of new entries is your vendors. Every time a software provider enables an AI feature in a product you already use, your inventory changes. That makes this a vendor-management problem as much as a governance one. Keeping that inventory current, with an owner and a lifecycle for every entry, is what AI Control Tower does.
The ability to show what AI you run, what it does, who owns it, and what evidence supports the decisions you made about it.
Readiness is not a certificate and not a legal opinion. It is an operational state.
And evidence is produced by the process rather than assembled when somebody asks.
This is our recommended process, not an official EU lifecycle. The AI Act sets obligations. It does not prescribe how to organize to meet them.
Four questions decide it.
Does it reach you geographically?
The Act has extraterritorial reach. Being outside the EU does not by itself put you outside scope.
What is an AI system?
The Act applies to systems meeting its own definition, not to all software. The Commission has published non-binding guidelines on that definition precisely because the boundary is not obvious.
What role do you hold?
Provider, deployer, importer, distributor, or none, for each system, not for the organization as a whole.
What is the use case, and in what context?
This drives the risk category. The Commission's position: the vast majority of AI systems in the EU fall into the minimal or no risk category, and the Act introduces no rules for them.
Most enterprises are deployers. But build something on top of a general-purpose model and put it into service under your own name, and the picture can change. The practical readiness question, per system: which role do we hold here and would a regulator agree?
We help you work through these questions system by system. Where the answer needs a legal determination, that is a question for counsel, and we will say so rather than guess.
If you have not yet decided which AI use cases are worth doing, start with AI Use Case Discovery.
The same model can sit behind a minimal-risk use case and a high-risk one.
The Act's risk categories are described by use, not by architecture. The Commission's own high-risk examples: scoring exams, sorting CVs, deciding creditworthiness. None is a model. All are things a model might be used to do.
Those six inputs produce a preliminary internal classification with a documented rationale. Most use cases clear at that point. The rest go to legal with the analysis already done.
Employment and worker management, including recruitment screening and performance tooling as well as access to essential services including creditworthiness. Both deferred to December 2027: time to prepare, not a permission to ignore.
Emotion recognition in the workplace is prohibited. Biometric categorization to infer protected characteristics is prohibited. Sentiment and emotion features appear in contact center, HR and productivity tooling more often than most organizations realize.
What readiness looks like in practice
Ownership
A named business owner and technical owner per use case. Where oversight is required, a named person with the competence, training and authority to intervene.
Governance
Registration, classification, approval thresholds tied to risk, escalation routes, a review cadence and exception handling. Defined once, applied consistently, light enough that people use it.
Documentation and evidence
Classification rationale, approvals, oversight design, vendor documentation and review history, captured as the work happens.
Technical controls
Logging and retention, permissions, disclosure where required, monitoring signals, and the ability to stop a system.
People and AI literacy
A legal obligation since February 2025 and the most commonly undocumented. The Act asks for understanding proportionate to role, context and risk. No certification is required. What is needed is a mapping from role and risk to a proportionate level of understanding, and a record that it happened.
High-risk AI needs more than a policy.
The high-risk requirements are the heaviest part of the Act, applying from December 2027. Most sit with the provider. If you are a deployer, your list is different and shorter, and these three are design decisions rather than paperwork.
Logs, for at least six months
Deployers must keep automatically generated logs under their control for at least six months. That is an architecture decision that has to be made before deployment.
Telling the workforce
Employers must inform workers' representatives and affected workers before putting a high-risk system into service. In Germany that intersects with works council rights, making it a sequencing question.
Oversight with authority
Human oversight must be assigned to people with the competence, training and authority to intervene. Organizations routinely assign oversight to somebody who understands the system but cannot stop it. That is not oversight.
A fundamental rights impact assessment is not required of every high-risk deployment. Under Article 27 it applies to public law bodies, private entities providing public services, and deployers of certain specific Annex III categories. Most private-sector deployers do not have that obligation.
Not sure where your readiness gaps are?
We find them with you, system by system.
Calling something an agent does not determine its risk. What it does determines that.
There is no separate legal category for AI agents. An agent is an AI system, assessed the same way as anything else. What agency changes is the weight of controls that already existed.
Permissions and identity
Which systems can it reach, acting as whom?
Actions
What can it do without approval?
Auditability
Can you reconstruct actions after the fact?
Ownership
Who is accountable, by name?
Stopping it
Who can, how fast, and has anyone tested that?
Those are the same questions you would ask about any automated process with system access. Agents make them more consequential, not different. Where you need runtime governance across agents and AI activity, that is what AI Control Tower is for.
AI governance belongs in the workflow, not in a spreadsheet.
Most organizations have a policy. What they do not have is the mechanism: registration without somebody remembering, classification before deployment, approvals with a name and a date, and reviews that actually fire.
Vendor-change monitoring, so a new AI feature in an existing tool becomes an entry rather than a surprise.
Every system becomes a record with an owner. Provider or deployer, purpose, data, people affected, named business and technical owners.
By use and context, not by vendor. The same model can be low-risk in one place and high-risk in another.
A named person signs off, and the threshold scales with the risk: low-impact clears on standing controls, anything touching people or a possible high-risk category goes to senior approval with classification, oversight and logging confirmed first.
Go-live only once the deployer duties are wired in.
Defined signals, so a change re-opens the file automatically: a vendor enabling a new AI feature, a shift in purpose or who's affected, accuracy drift, or an incident that carries its own reporting duty.
Classification, ownership and controls re-examined on a schedule, and pulled forward early when something moves.
A path, because a decommissioned system leaves behind live records.
The design principle: evidence should be produced by the process, not assembled for an audit.
Technology can operationalize governance. It cannot decide your regulatory obligations for you.
Readiness decides what has to be governed
Which systems exist, what role you hold, which obligations may apply, who owns what. That is judgment work.
AI Control Tower operationalizes it
Discovering AI assets, holding the inventory, running governance workflows, applying runtime controls over AI activity, and producing evidence.
The shipped EU AI Act content gives you the framework but not pre-built mappings to your control objectives. Assessment templates arrive in draft. ServiceNow itself states that it does not guarantee compliance and that customers remain responsible for their own. The software is genuinely useful and it is not a substitute for deciding which articles apply to you.
Regulation and useful AI are not opposites.
Governance that treats every use case identically produces two bad outcomes. Useful low-risk work stalls. And people route around the process, which is how you get shadow AI.
Fast path
Low impact, no personal data driving decisions, no affected individuals. Register, name an owner, apply standing controls, go.
Standard review
Personal data, customer-facing interaction, or a decision with modest consequence. Register, classify, document the rationale, confirm disclosure and oversight, approve.
Enhanced review
Decisions about people, significant consequence, or a possible high-risk category. Full assessment, legal input, oversight design, logging confirmed, senior approval.
Stop and escalate
Anything that looks like a prohibited practice, or where the answer is genuinely unclear.
These are operational governance tiers, not AI Act risk classifications. We keep the vocabularies separate because mixing them is how an internal label ends up being treated as a legal conclusion.
Nine dimensions.
We do not describe anything as compliant or non-compliant. That is a legal conclusion and it is not ours to reach.
What you leave with
The inventory
The assessment
The plan
What you do not leave with is a compliance opinion.
Readiness is not a state you reach, it is one you maintain.
Establish scope
Which entities, markets and parts of the business.
Build or validate the AI inventory
The long-lead item, including the AI you did not buy deliberately.
Map roles and use cases
Provider or deployer per system, flagging where the answer might change.
Assess readiness and risk
Preliminary classification with documented rationale, and the gap assessment.
Identify governance and evidence gaps
What is missing structurally, not from a folder.
Prioritize remediation
Live obligations first, then long-lead items, then December 2027. Sequenced against your capacity.
Operationalize
Build governance into the workflow so evidence is produced rather than gathered.
Establish ongoing review
Cadence, triggers, and what happens when a vendor changes a model underneath you.
We do not provide legal advice, and we do not certify AI systems.
We help translate regulatory requirements into operational and technical readiness. Where formal legal interpretation is required, we work alongside your counsel or recommend specialist advice.
The marginal questions come to counsel with the analysis already done, which makes that conversation shorter and cheaper.
Why Pulse & Patterns
AI plus operations
We work on how AI actually enters business processes, which is where the obligations attach.
Governance plus implementation
We translate requirements into operational controls and platform workflows, and then build them.
ServiceNow depth
We connect governance design to ServiceNow where it makes sense, and we know what the platform ships out of the box and what it does not.
Independent advice
On a subject where the easy commercial move is to recommend more software, we document the recommended system of record for each capability, including where an existing system is the better answer.
We are not a law firm. And Pulse & Patterns is a young company, founded in 2025, so the depth here comes from our senior practitioners' experience rather than from a long list of AI Act engagements.
Build a practical plan for EU AI Act readiness.
Start with what you actually have. We will help you find the AI, work out which obligations may apply and to whom, and give you a sequence you can defend, including the items that need your lawyers rather than us.
AI system
Software meeting the Act's own definition. Not all software qualifies.
Provider
You develop an AI system, or have one developed, and place it on the market under your own name.
Deployer
You use an AI system under your own authority in a professional context.
High-risk AI system
A category defined by use and context, not by the technology, carrying substantial requirements.
Prohibited practice
A use of AI the Act does not permit at all.
General-purpose AI
A model that can be used for many different things, such as a large language model.
Transparency obligation
A duty to tell people when they are dealing with AI, or that content was AI-generated.
AI literacy
A proportionate level of understanding for the people who work with AI. A live obligation, and no certification is required.
Fundamental rights impact assessment
A specific assessment required of some deployers, not all.
Data protection impact assessment
The equivalent assessment under data protection law. Related but not the same.
Human oversight
A named person with the competence, training and authority to intervene.
Shadow AI
AI running in the organization that nobody has recorded.
Agentic AI
Software that decides what needs to happen next and then does it, within rules you set.
What is the EU AI Act?
Regulation (EU) 2024/1689, the EU's framework law on artificial intelligence, in force since 1 August 2024. It takes a risk-based approach: some AI practices are prohibited, some AI systems are classified as high risk, some carry transparency obligations, and the majority fall into a minimal-risk category for which the Act introduces no rules. Amended on 27 July 2026 by Regulation (EU) 2026/1744, the Digital Omnibus on AI.
Was the EU AI Act delayed?
Partly. High-risk obligations were deferred: Annex III standalone systems to 2 December 2027, Annex I systems embedded in regulated products to 2 August 2028. The prohibitions, AI literacy, general-purpose AI model rules, transparency obligations and registration were not deferred. The Act became broadly applicable on 2 August 2026 and enforcement started then.
When does the EU AI Act apply?
Progressively. Prohibited practices and AI literacy since 2 February 2025. General-purpose AI model obligations since 2 August 2025. Transparency obligations, registration and enforcement from 2 August 2026. A new prohibition and a marking transition from 2 December 2026. High-risk obligations from 2 December 2027 and 2 August 2028.
Does the EU AI Act apply to my company?
It depends on four things. Whether the Act reaches you geographically, which it may even outside the EU. Whether what you use meets its definition of an AI system. What role you hold per system, most commonly deployer. And what each system is used for and in what context. The Commission's position is that the vast majority of AI systems in use in the EU fall into the minimal or no risk category.
How do I know whether an AI use case is high risk?
Not from the model or the vendor. The Act's categories are described by use and context: examples include exam scoring, CV sorting and credit scoring. Look at six things per use case: purpose, deployment context, who is affected, what data it uses, what decision it influences, and what actions it can take. That produces a preliminary classification with a documented rationale, which either clears or goes to legal.
What are the obligations of an AI deployer?
For high-risk systems, from 2 December 2027: use the system per its instructions, assign human oversight to people with competence, training and authority, ensure input data relevance where you control it, monitor operation, suspend and notify where risk emerges, report serious incidents, and keep logs for at least six months. Employers must inform workers' representatives and affected workers before deployment. The AI literacy obligation applies to deployers now, at every risk level.
Does the EU AI Act apply to AI agents?
Yes. An agent is an AI system assessed the same way. No separate legal category exists. What determines the obligations is what the agent does, in what context, to whom, with what data and autonomy. Agency raises the stakes on existing controls: permissions, human approval gates, auditability, ownership and the ability to stop it.
Does the EU AI Act apply to using a general-purpose AI assistant at work?
Using a general-purpose model does not make you a provider of that model. What applies is the deployer-side picture: the use case goes in your AI inventory, it needs an owner, it may need disclosure under the transparency obligations, it is covered by the AI literacy obligation, and its risk category depends entirely on what you use it for.
How does the EU AI Act relate to data protection law?
They sit alongside each other. Deployers of high-risk systems are directed to use the provider's information to support a data protection impact assessment where required, and a fundamental rights impact assessment complements that rather than replacing it. If you already have an impact assessment process, records of processing and a rights workflow, much of the AI Act's evidence apparatus can extend what you have.
Can software make us compliant?
No, and ServiceNow says so itself: its risk products help address regulatory requirements, but it does not guarantee compliance. Good tooling holds the inventory, runs the governance workflow, applies controls and produces evidence. It cannot decide which obligations apply to you, map regulatory articles to your controls, or own a decision.
Does Pulse & Patterns provide legal advice?
No. We provide readiness assessment, governance design, operating model recommendations, technical control requirements and implementation support. Where formal legal interpretation is needed, we work alongside your counsel or recommend specialist advice.