--- title: "AI governance and security" description: "AI inventories, risk classification, AI Act and ISO/IEC 42001 readiness, model security testing and human oversight designed in." url: https://www.expandware.com/services/ai/ai-governance-and-security/ section: "Services" topics: ["AI", "EU AI Act", "ISO/IEC 42001", "NIST AI Risk Management Framework", "OWASP Top 10 for LLM Applications"] publisher: "Expandware Private Limited" --- # AI governance and security AI inventories, risk classification, AI Act and ISO/IEC 42001 readiness, model security testing and human oversight designed in. AI your regulators and customers can trust. 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. Where it usually starts: - Nobody can produce a list of the AI systems in use across the organization. - A customer questionnaire asks how you govern AI, and the honest answer is that you do not yet. - An AI system may fall into a high risk category under the EU AI Act. - A model is exposed to users and has never been tested for prompt injection. 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. Where it sits: 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. 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. 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. 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. 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, not a client account.) What you have at the end: - 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. Standards and platforms worked with: EU AI Act, ISO/IEC 42001, NIST AI Risk Management Framework, OWASP Top 10 for LLM Applications, MITRE ATLAS, ISO/IEC 23894. Where it goes wrong, and 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. 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. 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. Common questions: Q: Does the EU AI Act apply to us? A: 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. Q: Should we certify against ISO/IEC 42001? A: 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. Q: Can you test our chatbot for prompt injection? A: Yes. We test for direct and indirect prompt injection, data leakage, jailbreaks and unsafe tool use, report findings by severity and retest after fixes. Q: What about staff using public AI tools? A: 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. Q: What counts as an AI system for an inventory? A: 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. Q: Who should be accountable for AI in an organization? A: 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. Q: What is MITRE ATLAS? A: 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. Q: How often should AI governance be reviewed? A: 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. Often paired with: Generative AI and agents, Governance, risk and compliance, AI strategy and readiness. --- Canonical page: https://www.expandware.com/services/ai/ai-governance-and-security/ Site index for machines: https://www.expandware.com/llms.txt Full site text: https://www.expandware.com/llms-full.txt Expandware Private Limited. Inquiries: solutions@expandware.com, +92 (333) 32 11011.