P.K. SHARMA
Cyber security intelligence, AI governance, practitioner analysis
Regulatory readiness
Classification of your AI systems under the EU AI Act, a conformity gap assessment, and a compliance plan sequenced against the enforcement timeline.
The EU AI Act applies in phases, and obligations differ sharply by risk class. Organisations that wait for full enforcement will retrofit governance under deadline pressure, at higher cost and with fewer options. This engagement establishes exactly which systems are in scope, what each one owes, and in what order to act.
EU AI Act
Risk classification, provider and deployer duties, conformity requirements
ISO/IEC 42001
The management system that carries most Act obligations
NIST AI RMF
Risk practice that satisfies both regulators and customers
GDPR interface
Where AI obligations meet existing data protection duties
Every AI system you build, buy, embed, or use informally, captured with enough detail to classify it. Shadow adoption is assumed and hunted for.
Each system placed in its Act risk class with the reasoning recorded, because regulators ask for the reasoning rather than the conclusion.
Provider, deployer, or both, determined per system, and the specific articles that follow from each answer.
What the Act requires for your risk classes against what exists today: technical documentation, data governance, human oversight, transparency, logging.
A plan ordered against the enforcement timeline, with the work that also earns ISO/IEC 42001 credit identified so effort counts twice.
Example scenario
A recruitment technology provider assumed one product was high-risk and the rest were out of scope entirely.
The work: Full inventory and classification found three in-scope systems, one of which carried provider duties nobody had considered.
Exposure understood a year before enforcement, with documentation built at a sustainable pace rather than in a panic.
Example scenario
A manufacturer deploying third-party AI in safety-adjacent processes could not tell whether it was a provider or a deployer.
The work: Role determination per system, then contractual work to pull provider evidence out of the vendors who genuinely held those duties.
Obligations landed with the right party, and vendor contracts were amended to supply the conformity evidence required.
Start the conversation
A short call to understand your situation; a clear scope if the engagement fits, and a straight answer if it does not.
Assess your exposureMost organisations built their AI Act plan around 2 August 2026. That date has moved: high-risk obligations were deferred by the Digital Omnibus to 2 December 2027 for standalone Annex III systems, and 2 August 2028 for AI embedded in regulated products.
Three sets of obligations did not move, and one of them is live now.
What moved, and what did not
So the question this engagement answers is not "are we ready for 2026". It is which of your systems are touched by the parts already in force, and whether the parts that moved will find you prepared or starting over.
The organisations that treated the Act as a management problem spent the deferral improving. The ones that treated it as a deadline project stopped, and will restart from a colder position with less time than they think.
Not risk tier. Role.
Obligations attach to what you are in relation to a specific system, not to your company in general. The same organisation is routinely a provider of one system, a deployer of another and an importer of a third, with different duties on each.
Two traps catch people here. Putting your own name on somebody else's model makes you its provider, with the full weight that carries. And substantially modifying a high-risk system does the same. Both are decisions made by procurement or engineering without anybody recognising them as regulatory events.
Getting the role wrong means every subsequent answer is about the wrong obligation set, which is why the assessment starts here rather than with a gap analysis.
The Act applies to providers placing a system on the EU market wherever they are established, and to providers and deployers outside the Union where the output of the system is used in the Union. A UK company serving EU customers is frequently in scope with no European entity at all.
It also arrives commercially, ahead of any enforcement. An in-scope customer passes its obligations down as contract terms, with evidence requests and timelines attached, and a supplier who cannot answer loses the account. That mechanism is faster and blunter than any regulator, and it is usually the one that actually arrives first.
The transparency duties applied from 2 August 2026 and are being widely overlooked underneath the noise about the deferral.
Tell people when they are interacting with an AI system. Mark synthetic audio, image, video and text in a machine-readable format. Disclose deep fakes. Disclose AI-generated text published to inform the public on matters of public interest, unless a human reviewed it and somebody holds editorial responsibility.
Two practical consequences. A chatbot on a marketing site is in scope, and a line in a privacy notice is not the disclosure the Article asks for. And machine-readable marking is a task for whoever owns the publishing pipeline, not for whoever owns the copy.
It is not a certification, and nothing here produces one. The Act is law and compliance is demonstrated to a market surveillance authority, not evidenced by a certificate.
It is not an ISO 42001 project either, although the two overlap heavily. A management system produces most of the evidence the Act asks for as a by-product of operating, which is a considerably better position than assembling it under time pressure. Where certification is also wanted, saying so early avoids doing the same work twice in two shapes.