AI
AI your regulators and customers can trust.
AI inventories, risk classification, AI Act and ISO/IEC 42001 readiness, model security testing and human oversight designed in.
Sound familiar
Where this usually starts.
Regulators now expect organizations to know which AI systems they use, what risk each carries and who is accountable for it, and customers ask the same questions in procurement. We build the governance that answers them: an inventory of AI in use, including the tools staff adopted on their own, a risk classification for each system, controls and documentation proportionate to that risk, and security testing against the attacks that target models specifically.
Scope
What is included.
-
AI inventory
Every AI system in use, including embedded and staff-adopted tools, with an owner for each.
-
Risk classification
Each system classified under the AI Act and your own risk appetite.
-
Management system
Policies, roles and processes aligned to ISO/IEC 42001.
-
Documentation
Technical documentation, logging and transparency notices where the law requires them.
-
Model security testing
Prompt injection, data leakage and jailbreak testing against the OWASP risks for language models.
-
Human oversight
Review points designed into workflows wherever a decision affects people.
Reference architecture
AI that answers from your data, on infrastructure you control.
Governance and security sit across the AI architecture: guardrails on the serving path that limit what models may do, and the governance and audit function that records which systems exist, who owns them and how each is controlled.
What this service delivers here
-
Guardrails
Checks every input and output for leakage, injection and policy before it moves on.
-
Governance and audit
The inventory, risk classification and logs a regulator can ask for.
Before you start
Decisions to settle early.
-
Certify or align
Certification against a management standard reassures some customers; alignment without certification is cheaper and often enough. Your customers and regulators decide.
-
How strict to be on staff tools
Blocking public AI tools drives use underground; allowing everything leaks data. An approved route with clear limits usually works best.
-
Who signs off a high risk system
Somebody senior has to accept the residual risk of each significant AI system. We define who, and what they need to see.
Approach
How the work runs.
-
Inventory
Every AI system in use, with owners
-
Classify
Risk under the AI Act and your policy
-
Control
Documentation, oversight and testing
-
Monitor
Reviews as systems and laws change
Commercials
How it is bought.
-
A fixed-fee assessment
We inventory the AI systems in use, classify a sample against the AI Act and your risk appetite, and run a short security test on an exposed model. You get the findings and a fixed price for the full program.
-
A fixed-price build
The complete inventory, risk classification, policies and roles, documentation and model security testing for the systems in scope, at a fixed price.
-
Running it afterwards
Governance continues as a monthly or quarterly service if you want it: reviewing new systems, retesting models after change and keeping records current as the law develops.
Start with the assessment.
Worked example
A questionnaire with no honest answer.
Say a software company sells to banks, and a customer's procurement questionnaire asks how it governs AI. Its product includes a model-based feature, staff use several AI tools, and none of it is written down.
-
Inventory
We list every AI system in use, from the product feature to the assistants staff adopted on their own, and give each one an owner.
-
Classify
Each system is classified under the EU AI Act and the company's own risk appetite, and the product feature is tested for prompt injection and data leakage.
-
Control
Policies, documentation and human review points are put in place in proportion to each system's risk, and the test findings are fixed and retested.
-
Answer
The questionnaire is answered from the evidence, and the same material becomes the start of a management system the company can extend.
At the end, the company answers AI questions in procurement from records rather than reassurance, and a new AI tool passes through an approval route before anyone uses it.
An illustration
Where it goes wrong
What we design out.
-
An inventory that misses embedded AI
Surveys find the tools people mention and miss the AI inside software you already buy. The inventory includes a review of your software estate.
-
Policy without enforcement
A policy nobody can follow is ignored. Approval routes are short, clear and built into how tools are bought.
-
Testing once, at launch
Models and prompts change after they ship. Security testing is repeated whenever a system changes materially.
Outcomes
What it changes.
-
A complete picture
You know which AI systems exist, what they touch and who answers for them.
-
Obligations met in proportion
Controls match the risk of each system, so low risk tools are not buried in process.
-
Answers for procurement
Customer and regulator questions about AI are answered from documents that already exist.
How you will know it is working
- You can produce a current list of AI systems with an owner for each.
- Procurement questionnaires about AI are answered from records.
- New AI tools pass an approval route before staff use them.
- Exposed models are retested after every significant change.
You keep
What you have at the end.
Handover pack
five items
- AI system inventory and risk register Every AI system in use, its owner, its purpose, its risk classification and the controls applied to it.
- AI policy and governance roles Who approves AI use, who is accountable for each system, and the rules staff work to.
- Gap assessment against the AI Act and ISO/IEC 42001 Where your current practice meets each requirement, where it does not, and what closing each gap involves.
- Model security test report Prompt injection, data leakage and jailbreak findings, each with reproduction steps and a fix.
- Documentation templates and transparency notices Templates for technical documentation and logs, and the notices users must see when they deal with AI.
The team
Who you work with.
-
Governance lead
Builds the inventory, the risk classification and the policies, and maps them to the law.
-
AI security tester
Tests exposed models for prompt injection, data leakage and jailbreaks.
-
Documentation specialist
Prepares technical documentation, logs and transparency notices where they are required.
What we need from you
- A list of known AI tools and features, however partial.
- Access to the owners of AI systems in your products and operations.
- A test environment for the models to be security tested.
- Legal counsel to confirm how the law applies to you.
From the GPU to the governance, one team answers for the model.
Questions
Questions we get asked.
Does the EU AI Act apply to us?
It applies to providers and deployers of AI systems placed on the EU market, or whose output is used in the EU, wherever they are based. Which obligations apply depends on the risk category of each system, which is why classification comes first.
Should we certify against ISO/IEC 42001?
Certification is worth it when customers or regulators ask for independent assurance of how you manage AI. Many organizations align first and certify later; either way, the certificate itself comes from an accredited certification body.
Can you test our chatbot for prompt injection?
Yes. We test for direct and indirect prompt injection, data leakage, jailbreaks and unsafe tool use, report findings by severity and retest after fixes.
What about staff using public AI tools?
We find them as part of the inventory, then help you decide which to approve, which to replace with a governed alternative and how to explain the policy to staff.
What counts as an AI system for an inventory?
Anything that produces predictions, content, recommendations or decisions from data: models you build, AI features inside software you buy, and the assistants staff use on their own. Embedded features are the ones most often missed, which is why the inventory includes a review of your software estate, not only a survey.
Who should be accountable for AI in an organization?
Each AI system needs a named business owner accountable for its use and its outcomes, supported by a governance function that sets policy and keeps the inventory. Accountability placed only with IT tends to cover the technology and miss the decisions the system affects.
What is MITRE ATLAS?
A knowledge base of tactics and techniques used to attack machine learning systems, modeled on MITRE ATT&CK. We use it with the OWASP risks for language models to plan security testing, so the tests cover attacks seen in practice rather than a generic checklist.
How often should AI governance be reviewed?
Whenever a system changes materially, a new one is adopted or the law changes, and on a regular schedule in between. The inventory and risk register are living records, and a review is a short check of each entry rather than a fresh project.
Ask about your situation
Answered from this site, with its sources.
Where it is bought
AI governance and security, by sector and region.
Sectors that buy AI
Often paired with
What usually comes next.
CONTACT
Know every AI system you are accountable for.
Start with an AI inventory and risk classification. You get a written register and a gap assessment you can act on.
- Senior-led
- Accountable
- Direct
- Fixed-price options
- Compliance-ready
- 24/7 capable
Prefer to talk it through? Call +92 (333) 32 11011
What happens next
-
You pick the time
Tell us which AI tools and features you know are in use; we fit the call to your week.
-
Thirty minutes, with an engineer
A governance lead discusses where the AI Act is likely to apply and what customers are asking.
-
A written assessment
It sets out the gaps, the test findings and a fixed price for the program.