P.K. SHARMA
Cyber security intelligence, AI governance, practitioner analysis
AI strategy
Working out which AI systems and agents an organisation actually needs, and how to adopt them safely under NIST AI RMF, the EU AI Act, and the UK's principles-based approach.
Most organisations do not have an AI strategy problem; they have an AI selection problem. The work answers the questions that matter before any tool is bought: which AI systems and agents the business actually needs, what they should be allowed to do, and which regulations apply to each of them.
NIST AI RMF
Risk framing across Govern, Map, Measure, and Manage
EU AI Act
System classification and obligation mapping by risk class
UK approach
The principles-based framework applied by UK regulators
ISO/IEC 42001
Alignment so governance work counts towards certification later
Map every AI system in use or planned: sanctioned tools, shadow adoption, vendor features, and internal builds. The inventory becomes the register everything else references.
Assess where AI and agentic automation genuinely fit your operations, and where they do not. Each candidate use case is scored for value, data sensitivity, and blast radius.
Classify each system under the EU AI Act, map NIST AI RMF functions, and record the UK regulatory expectations that apply to your sector.
A sequenced adoption roadmap: which systems to deploy, in what order, with what permissions, and the governance controls each one needs from day one.
Ongoing advisory as delivery proceeds, with board reporting that turns AI risk into decisions directors can actually take.
Example scenario
A mid-sized professional services firm discovered staff were using more than twenty unsanctioned AI tools across drafting, transcription, and analysis.
The work: Inventory first, policy second: telemetry-based discovery, risk ranking by data sensitivity, then a sanctioned toolset with clear boundaries and staff training.
Shadow use collapsed into an approved set of tools, client data exposure ended, and the firm gained a defensible register to show clients and insurers.
Example scenario
A product company wanted to add agentic features that could act on customer accounts, without understanding the permission and liability implications.
The work: Agent capability mapping and least-privilege design before build, plus EU AI Act classification of the planned system and contractual guardrails for the model vendor.
The feature shipped with scoped, auditable agent permissions and a documented risk classification that satisfied enterprise customer due diligence.
Start the conversation
A question about this area, an invitation to speak, or a role you think fits: write, and you will get a straight answer.
Get in touchMost of this work begins with a stated question: which model should we use, is this vendor safe, do we need a policy. Those are real questions and they are almost never the constraint.
The constraint is usually that nobody can say what AI the organisation already runs. Not because anyone concealed it, but because most of it was never adopted as a decision. A supplier shipped a feature into software already licensed. Somebody expensed a subscription below the procurement threshold. A proof of concept was built, worked, and quietly became load-bearing.
Until that list exists, every other question is being answered about a system whose shape nobody knows. That is why the first phase is an inventory rather than a strategy, and why it usually takes longer than expected and changes what the strategy needed to be.
Record every system in one of three states
The second failure is a governance programme that generates artefacts nobody uses. Policies written for an auditor, a risk register updated quarterly by one person, an impact assessment that is a data protection assessment with a new cover page.
The test applied here is whether an artefact was produced as a by-product of work actually happening. A review record with a date and a name is evidence. A policy stating that reviews happen is a description of an intention.
That distinction decides what gets built. Ownership that somebody knows they hold. A route for a person affected by a decision to challenge it. Logging of what a system did rather than only what it said. Each is small, and each is the thing an assessor, a regulator or an incident will ask for first.
The EU AI Act reaches organisations outside the Union through the market and output tests, so a UK company serving EU customers is often in scope without holding a European entity. Its high-risk obligations moved to December 2027 and August 2028, but three other sets did not move, and Article 50 transparency has applied since August 2026.
ISO 42001 is voluntary and discharges no legal obligation. What it does is produce most of the evidence the law asks for, as a by-product of running the management system, which is a considerably better position than assembling it under time pressure.
Advice here is about which of those matters to you and in what order, rather than about compliance in general. Most organisations need less than they fear and need it sooner than they think.
Personally, by one practitioner, which sets the ceiling on how much runs at once and is the reason the work takes the shapes it does.
No product is resold, no tooling is bundled, and there is no partner arrangement that makes one answer more profitable than another. That independence is worth stating because it is the thing you cannot verify from the outside, and it changes what advice is available to give.