AI Security and Compliance Services | ATH Infosystems

AI security and compliance you can show an auditor

ATH builds AI security, governance and compliance into the agents, enterprise search and assistants we deliver, and into AI you already run. Each system is designed around the rules you answer to, including HIPAA, GDPR, SOX and PCI DSS. We test it against attack before launch and log what it does, so you can show how it behaved.

Fixed-price AI risk assessment for an agreed scope. First findings in about two weeks.

AI control log

6 controls running

Example: six security and compliance controls acting on live AI traffic. An injected instruction is blocked, patient and card data are masked, a restricted document is kept out of search results, a large refund waits for approval and every decision is logged.

  1. Input screening Stopped an instruction hidden in an uploaded PDF before it reached the modelBlocked
  2. Privacy filter Masked a patient’s name and member ID before the prompt left the networkMasked
  3. Search permissions Kept payroll files out of the search results for a user without HR accessFiltered
  4. Card data Swapped a card number typed into chat for a stand-in code and kept it out of the logsTokenized
  5. Approval gate Held an $18,400 refund raised by an agent until a manager signs offNeeds approval
  6. Audit trail Recorded the request, sources, answer and approver for each decisionLogged
Example activity, Eastern TimeEvery event kept as audit evidence

AI reached production faster than its controls

AI went into production quickly, and the studies below suggest its controls did not keep pace. Attackers, auditors and regulators have all noticed.

$4.8B

Forecast market for securing AI in 2027, up 68.7% from 2026.

Source: Gartner, August 2026
92%

Among organizations hit by a breach of their own AI models or applications, the share that lacked proper AI access controls. About one in five breached organizations in the study reported such a breach.

Source: IBM, Cost of a Data Breach Report 2026
31%

Share of organizations that say they are fully equipped to control and secure AI agents, although 83% plan to deploy them.

Source: Cisco AI Readiness Index 2025
40%

of enterprises will scale back or switch off autonomous AI agents by 2027, Gartner predicts, because of governance gaps found only after something goes wrong in production. We build to close those gaps first: controls sized to what each agent is allowed to do, an attack test before launch and audit evidence from the first day.

AI security, governance and compliance services

Eight areas of work. Take the full program, or start with the one that is holding your AI project up.

Govern

An inventory of the AI in use, a risk rating for each new use case, vendor review and an approval path people will use.

Protect data

Sensitive data found, classified and masked before it reaches a model, encrypted in transit and at rest, with deletion that covers prompts, logs and search indexes.

Secure the application

A threat model before build, containment for prompt injection, search that respects permissions, and one gateway for model and tool traffic.

Secure agents

A separate identity for each agent, an approved list of tools, credentials that expire, and limits and approval gates on high-impact actions.

Test

Red teaming before launch, automated attack tests that block a release when they fail, and checks for accuracy, grounding and bias.

Monitor and respond

A trace of every request and tool call, alerts sent to your security team’s tools, an incident plan and a stop switch.

Prove it

Controls mapped to your rules, the technical input for impact assessments, and an evidence pack for audits and customer security questionnaires.

Train your people

An acceptable-use policy staff can follow, secure-build guides for developers and briefings for approvers, executives and the board.

For ISO 27001, SOC 2 and GDPR readiness across your whole company, see our cybersecurity compliance services.

What goes wrong with AI, and how we control it

AI systems fail in ways ordinary software does not. These are the failures we design against.

AI risks, what each looks like in practice and the controls that address it
RiskWhat it looks likeHow we control it
Prompt injectionA user, a web page, an email, an uploaded file or a tool result slips in instructions, and the model follows them instead of yours.No model resists this reliably and no screen catches every attack, so we limit what a hijacked model can do. We treat everything a model reads as untrusted and screen it. An agent that reads untrusted content is not also given private data and an open channel to the outside, and any action that reaches outside the system needs a check outside the model or a person’s approval.
Sensitive data exposurePatient, card or customer data ends up in a prompt, an answer, a log file or a vendor’s training set.We screen for personal, health and card data and mask or tokenize it before a prompt reaches a model, where possible. Detection misses some values, so we also choose model services whose terms exclude training on your data. Logs are redacted by default, and each record is kept for as long as your retention schedule says.
Agents with too much powerAn agent with broad access deletes records, moves money or emails customers because it misread a request or was manipulated.We give each agent its own identity and a named owner, read-only access by default, credentials that are limited to the task and expire, limits on amount and volume, and approval gates on high-impact or irreversible actions.
Search that ignores permissionsEnterprise search answers with a document the person asking is not allowed to open.We carry the source system’s access lists into the search index and filter every query by who is asking. Permission changes reach the index within an agreed time, each customer or business unit has its own index, and documents that must never surface are part of every release test.
Confident wrong answersThe model invents a policy, a dosage or a contract clause, and someone acts on it.Answers come from your approved sources and cite them, and the system is built to say when support is missing and hand off to a person. We measure accuracy on expert-built test sets before each release. That lowers the error rate without removing it, so answers with legal, financial or clinical effect go to a person.
Poisoned data, models and memoryA tampered document, dataset, tool server or downloaded model quietly changes how the system behaves, or an agent stores a planted instruction and acts on it weeks later.We index only approved sources, each with an owner and origin on record. Models and libraries come from an approved registry with fixed versions and integrity checks, and an AI bill of materials lists what each release contains. What an agent may keep in memory is limited and expires.
Agents that trust each otherIn a team of agents, one passes a planted instruction or its own access to the next, and a small error spreads through the whole workflow.Agents prove who they are to each other, a message from another agent is treated as untrusted input, no agent can hand on more access than it holds, and limits apply to the whole chain as well as to each agent.
Unchecked outputA model’s answer is passed straight to a browser, a database or a command line, and carries an attack with it.We treat model output as untrusted input: checked against a fixed format, encoded for where it is going and never run as code outside a sandbox. Links and images in an answer are blocked or sent through a proxy, because that is a common way a hijacked answer leaks data.
Leaked prompts and secretsSystem prompts, API keys or internal rules are coaxed out of the model.We keep secrets in a vault and add them at the tool layer, out of the model’s view. Access rules are enforced in code, not in prompt wording, and we write prompts on the assumption they will be read.
Runaway cost and abuseA script or a looping agent drives thousands of expensive model calls overnight.We set quotas for each user and agent, limits on steps and run time, alerts on unusual usage and a switch that stops a system at once.
Shadow AIStaff paste company data into AI tools nobody reviewed or approved.We build the inventory from sign-in, network and spending records, not from a survey, then offer an approved route that is easier than the workaround and a policy people can follow.
No evidenceAn auditor asks who approved a decision, and nobody can show them.We keep a record for each decision: who asked, which agent acted, the sources and the model and prompt versions used, the tools called and who approved. Records are stored so that any later change is detectable. They hold masked values, with full prompts in a separate store that has tighter access and a shorter life, so a deletion request can be met without breaking the audit trail.

The first ten rows cover the ten entries of the OWASP Top 10 for LLM Applications (2026 edition) and draw on the OWASP Top 10 for Agentic Applications. The last two are the governance gaps we see most often.

Eight layers between a request and your data

No single filter makes AI safe. We put a control at every step of a request, so when one layer misses something, the others limit how far it can go.

  1. Identity and access

    Confirms who or what is asking, whether a person, a service or an agent, and what it is allowed to do.

  2. Gateway and policy

    One entry point for model and tool traffic applies your policies, rate limits and budgets before anything reaches a model.

  3. Input and data protection

    Screens prompts, files, search results and tool results for injected instructions, then masks or tokenizes the regulated data it finds.

  4. Permission-aware search

    Fetches only what the person asking is allowed to see, from approved sources with a version history.

  5. Model access

    Calls approved models, locked to a dated version, under terms that exclude training on your data. Private connections and keys you hold where the provider offers them.

  6. Agent and tool control

    Checks each tool an agent calls against an approved list, with credentials limited to the task, a sandbox for running code, run limits and approval gates for high-impact actions.

  7. Output control

    Checks answers for unsupported claims, regulated data and unsafe content before they are shown, stored or run, and restores masked values only for people entitled to see them.

  8. Audit and evidence

    Records every step, raises alerts and keeps the audit trail your evidence comes from.

An agent repeats steps 3 to 7 on every turn, so whatever a search or a tool returns is screened again before the model acts on it. The same design runs on AWS, Microsoft Azure or Google Cloud, inside your own cloud account or on-premises, and with OpenAI, Azure OpenAI, Anthropic, Google Gemini or open-source models you host yourself.

AI agent security: as much freedom as the risk allows

One level of control does not fit every agent. We set an autonomy level for each task and tighten the controls as the stakes rise.

Level 1

Observe

Reads, searches and summarizes. It cannot change anything, but it can still expose what it reads, so the data controls apply in full.

  • Read-only access
  • Sees only what the user may see

Level 2

Advise

Drafts and recommends. A person carries out the action.

  • Can save drafts, cannot send or post them
  • Sources shown with every suggestion

Level 3

Act with approval

Prepares the action. A named person approves it before it runs.

  • Approval gate outside the model
  • Approver sees the exact action, not the agent’s summary of it
  • Approver recorded in the audit trail

Level 4

Act within limits

Runs on its own inside limits you set, for routine work that can be undone.

  • Caps on amount, volume and scope
  • Anything outside the limits drops to Level 3
  • Alerts and a stop switch

At every level an agent has its own identity, an approved list of tools, credentials that expire and a full audit trail. When it works on a person’s behalf it can read only what that person may read. When a schedule or an event starts the work, it runs under its own narrowly scoped account with a named owner. We vet the servers that supply its tools, including Model Context Protocol (MCP) servers, lock each to a set version, approve it again when it changes and treat what it returns as untrusted.

AI controls mapped to HIPAA, GDPR, SOX and PCI DSS

Regulators rarely write a new rulebook for AI. They apply the rules you already follow to a new kind of system, then add AI-specific duties on top. We map each AI system to both, in terms your compliance team can check.

Check every box that describes your AI system

HIPAA

HIPAA is technology-neutral. An AI system that handles protected health information is covered like any other system that does.

What it expects

  • A business associate agreement with every vendor that handles patient data for you, AI providers included
  • Use and disclosure limited to the minimum necessary
  • A risk analysis that covers the AI system, with unique IDs, access controls and audit logs that are reviewed

What we build

  • Patient identifiers screened for and masked before a prompt reaches a model, where possible
  • Each task sends the model only the fields it needs
  • A design that uses only model and cloud services available under a business associate agreement
  • Role-based access for people and for agents, and a log of every AI access to patient data

Evidence you can show

  • A data-flow map of where patient data goes
  • The agreements in place for each AI vendor
  • The risk analysis entry for the AI system
  • Access reviews and audit-log reports

What stays with you: you remain the covered entity or business associate. Your policies, staff training, patient rights and notices to patients and regulators are yours to run.

HHS proposed an update to the Security Rule in January 2025. As of November 2026 it has not been finalized, so the current rule applies. Sources: 45 CFR 164.308, 164.312 and 164.502, and the federal regulatory agenda.

GDPR

The GDPR applies to personal data your AI system processes if you are established in the EU, or if you offer goods or services to people in the EU or monitor their behavior there. The UK applies its own version, the UK GDPR, amended by the Data (Use and Access) Act 2025.

What it expects

  • A lawful basis and a stated purpose, and no more personal data than that purpose needs
  • A contract with every processor, AI providers included, and a lawful route for any transfer of personal data out of the EU or UK
  • A data protection impact assessment (DPIA) where processing is likely to be high risk
  • Limits on decisions made solely by automated means that significantly affect people. The EU allows them only in specific cases, and the person can ask for human review
  • Security that fits the risk, and privacy designed in from the start

What we build

  • Data minimization in every pipeline, and pseudonymization where the task allows
  • Deployment in your own cloud account or on-premises, with models hosted in the region you choose, to help keep data where you need it
  • Retention and deletion that reach prompts, logs and search indexes
  • Human review steps for decisions about people

Evidence you can show

  • The system description, data flows and safeguards your impact assessment needs
  • A record of what personal data the system processes and why
  • Processor terms, processing locations and the transfer mechanism for each model service
  • Decision and review logs

What stays with you: you remain the controller. The lawful basis, notices to individuals and answers to their requests are yours, with your data protection officer.

Under the EU GDPR, fines for the most serious infringements can reach €20 million or 4% of worldwide annual turnover, whichever is higher. Sources: GDPR, Regulation (EU) 2016/679 and GOV.UK, Data (Use and Access) Act 2025.

Sarbanes-Oxley (SOX)

SOX has no AI-specific rule. If your company files reports with the SEC, an AI system that performs or feeds a control over financial reporting falls under the same internal-control expectations as any other system in that process.

What it expects

  • A yearly management assessment of internal control over financial reporting, with evidence to support it (Section 404)
  • Sound IT general controls behind any automated control, for example over program changes and access to programs and data

What we build

  • Change control for prompts, models, tools and agent settings: versioned, reviewed and approved
  • Segregation of duties: the agent’s account can prepare an entry or payment but holds no right to post or release it
  • Inputs, output and model version kept for every run, so a result can be checked again later
  • Access reviews that cover agents as well as people

Evidence you can show

  • A description of the AI-assisted process and its key controls
  • Change tickets, approvals and test results for each model or prompt change
  • Logs that tie every AI-prepared entry to its approver
  • Access review records

What stays with you: management’s assessment and sign-off, and the testing your auditors perform.

Source: SEC guidance on management’s report on internal control over financial reporting.

PCI DSS

PCI DSS v4.0.1 is the current version. The PCI Security Standards Council’s guidance on AI says that using AI removes no requirement and that AI is scoped like any other technology.

What it expects

  • Every system that stores, processes or transmits cardholder data, or that could affect the security of those systems, is in scope, AI components included
  • Council guidance: give an AI system as little sensitive data as possible, and card data only when it is suitably protected
  • Council guidance: AI activity is logged and monitored, with a person accountable for it

What we build

  • Card numbers screened for and tokenized, and security codes discarded, before they reach a prompt, model context or log
  • A design that keeps AI services outside the cardholder data environment where it can
  • No card data in training, test or evaluation sets
  • AI activity logged into your existing monitoring

Evidence you can show

  • Scope and data-flow diagrams that show the AI components
  • Tokenization and redaction test results
  • Log samples showing no card numbers
  • Your AI and cloud providers’ attestations of compliance, with a matrix of who is responsible for each requirement

What stays with you: your own PCI DSS assessment and attestation.

The Council’s AI guidance is not mandatory; the standard itself takes precedence. Sources: PCI Security Standards Council, AI Principles (2025) and Security Considerations for AI Systems (2026).

EU AI Act

The AI Act sorts AI systems by risk. Some duties already apply, and the requirements for high-risk systems were postponed in 2026.

What it expects

  • Prohibited practices have been banned since February 2, 2025. Since the same date, providers and deployers must take measures to support their staff’s AI literacy
  • Since August 2, 2026, people must be told when they are dealing with AI, and AI-generated content must be marked. For generative AI systems already on the market before that date, marking is due from December 2, 2026
  • High-risk requirements apply from December 2, 2027, for stand-alone uses such as hiring and credit scoring, and from August 2, 2028, for AI built into regulated products

What we build

  • A proposed risk class for every use case, for your counsel to confirm
  • Notices that tell users they are dealing with AI, and marking of generated content
  • Documentation, logging and human oversight designed in for higher-risk systems
  • Testing for accuracy, robustness and security, and AI literacy training for the teams that build, approve and use AI

Evidence you can show

  • An AI inventory with the proposed risk class of each system and the reasoning
  • Technical documentation and logs
  • Test and monitoring records
  • Human oversight procedures

What stays with you: deciding with counsel whether you are a provider or a deployer, and any registration or conformity assessment the Act requires of you.

Fines can reach €35 million or 7% of worldwide annual turnover, whichever is higher, for prohibited practices, and €15 million or 3% for most other breaches. The high-risk dates were set by Regulation (EU) 2026/1744. Sources: European Commission, AI Act overview and questions and answers; Regulation (EU) 2026/1744.

US state laws

No federal statute preempts state AI laws as of November 2026, so they apply state by state. A December 2025 executive order directs federal agencies to challenge some of them, so expect this to keep moving. Federal anti-discrimination and credit laws still apply whatever technology makes the decision.

What they expect

  • California: rules on automated decision-making technology took effect January 1, 2026. Businesses that use it for significant decisions must comply starting January 1, 2027, and risk assessments are already required
  • Colorado: a May 2026 law replaced the state’s 2024 AI Act before its duties began. From January 1, 2027, developers must give the businesses that deploy their systems technical documentation. Deployers’ duties, expected from the same date, center on notice, a plain-language explanation of adverse outcomes, correction of wrong data and human review on request
  • Hiring and employment: California (since October 1, 2025), Illinois (since January 1, 2026) and New York City (enforced since July 5, 2023) limit discriminatory use of AI, with notice duties in Illinois and New York City and a yearly bias audit in New York City
  • Texas: since January 1, 2026, a ban on certain intentional harmful uses of AI, and a duty on state agencies and health-care providers to tell people when AI is used

What we build

  • Risk assessments for systems that make or shape decisions about people
  • Notice, explanation and appeal paths, with a human reviewer
  • Bias testing before launch and on a schedule, and support for an independent bias audit where a law requires one
  • Technical documentation of each decision system for the business that deploys it
  • Records kept for the periods your counsel sets

Evidence you can show

  • Risk assessments
  • Bias test results
  • The notices and explanations people receive
  • Review and appeal logs

What stays with you: the legal view of which state laws apply to you, and the notices you give consumers and employees.

Thresholds and exemptions apply. Sources: California Privacy Protection Agency, Colorado SB26-189 (official summary), New York City DCWP and Texas HB 149.

GLBA Safeguards Rule

The FTC’s Safeguards Rule requires non-bank financial institutions under FTC jurisdiction, such as mortgage lenders and brokers, finance companies, collection agencies and tax preparers, to protect customer information with a written security program. Banks and credit unions follow their own regulators’ safeguards rules. Either way, an AI system that handles customer information belongs inside the program.

What it expects

  • A written security program led by a Qualified Individual, built on a written risk assessment
  • Access controls, encryption of customer information, multi-factor authentication and change management
  • Logging and monitoring, security testing and oversight of service providers
  • Notice to the FTC as soon as possible, and no later than 30 days after discovery, when unencrypted customer information of 500 or more consumers is acquired without authorization

What we build

  • AI systems added to your risk assessment and data inventory
  • Encryption of customer information, multi-factor authentication for the people who use and run the AI system, and short-lived, least-privilege credentials for agents
  • A review of each AI provider as a service provider
  • AI activity logged into your monitoring

Evidence you can show

  • The updated risk assessment and inventory
  • Service-provider reviews and contract terms
  • Access and encryption settings for the AI system
  • Test and monitoring records

What stays with you: your Qualified Individual, the written program and reporting to your board.

Source: Federal Trade Commission.

Standards and frameworks

Where no law prescribes how, voluntary frameworks are the usual way to show customers and auditors that your AI is governed.

What they are

  • NIST AI Risk Management Framework and its Generative AI Profile: the voluntary US framework for managing AI risk
  • ISO/IEC 42001: the international standard for an AI management system. Independent bodies certify against it
  • SOC 2: examined against the existing criteria today. In October 2026 the AICPA published a draft update that adds AI points of focus; if approved, it applies to engagements beginning on or after December 31, 2027
  • OWASP Top 10 lists and MITRE ATLAS: the reference lists of AI risks and attack techniques

What we build

  • A governance model organized around the four NIST functions: govern, map, measure, manage
  • The policies, risk assessments and records an ISO/IEC 42001 management system asks for
  • AI components added to your SOC 2 system description and controls
  • Threat models and test plans labeled to OWASP and MITRE ATLAS

Evidence you can show

  • AI policy, roles and risk assessments
  • One control mapping across the frameworks you follow
  • Test reports labeled to recognized attack catalogs

What stays with you: the choice of scope and the audit itself. Certificates come from accredited certification bodies and SOC 2 reports from licensed CPA firms, not from us.

Sources: NIST, AICPA, the OWASP GenAI Security Project and MITRE ATLAS.

We are engineers, not your lawyers. Nothing on this page is legal advice. Your counsel and compliance team decide which rules bind you. We build the controls, test them and hand over the evidence. Your compliance and security teams review each system’s design, data access and approval rules before it goes live. Dates and status were checked in November 2026 and will change.

What you can hand an auditor

Controls only count if you can show they ran. A full engagement leaves you with an evidence pack your auditors, customers and insurers can read.

  • AI inventory and risk register The AI systems and tools found in use, who owns each, what data it touches and how it is rated.
  • Data-flow maps Where personal, health, card and financial data goes, including vendors and model providers.
  • Impact assessment input The system description, data flows, risks and safeguards your privacy team needs for its assessments.
  • Control matrix Each control mapped to the requirements of the rules and standards you follow.
  • Security test reports Each finding with its severity, the fix and the re-test result, plus the risks that remain and who owns them. These are our own tests; where a rule calls for an independent tester or auditor, we support theirs.
  • Model and vendor reviews Each provider’s terms on data handling, retention and training, summarized for your counsel and procurement team.
  • AI bill of materials The models, versions, datasets, prompts, libraries and tool servers in each release.
  • Change and access records Approvals and test results for each change to a model, prompt or tool, and reviews of who and what has access.
  • Policies and incident plan Acceptable use, approval paths, human oversight and the AI incident plan.
  • Audit logs and evidence exports Records of inputs, sources, outputs, approvals and changes, stored so that tampering shows.

What changes by industry

The controls are the same everywhere. What changes is the data at stake and the rule that governs it.

Typical AI uses, the first risk and the controls and rules in play for six industries
IndustryTypical AI useWhat goes wrong firstWhat we put in place
HealthcarePatient support, scheduling and clinical paperworkPatient data in prompts and logsMasking before the model, access and audit logs, and sensitive cases routed to a clinician. Rules in play include HIPAA.
Banking and financeOnboarding, lending support and compliance researchDecisions nobody can explain, and model changes nobody reviewedHuman review of decisions about people, change control and a complete audit trail. Rules in play include fair-lending law, GLBA and SOX.
InsuranceClaims intake and underwriting supportOutcomes that are unfair or cannot be explainedBias testing, plain-language explanations and a person signing off on adverse decisions. Rules in play include state insurance and AI laws.
Retail and e-commerceCustomer service, product search and order handlingCard numbers typed into chat, and agents issuing refunds uncheckedCard numbers tokenized before the model, spending limits and approval gates. Rules in play include PCI DSS and state privacy laws.
Legal and professional servicesContract review and researchConfidential documents reaching the wrong reader, and invented citationsSearch limited to each matter’s permissions, private deployment and answers that cite their sources.
Software and SaaSAI features inside your own productOne customer’s data surfacing for another, and stalled enterprise security reviewsSeparation of each customer’s data, controls each customer can set, and evidence for SOC 2 and security questionnaires.

Your first AI system assessed, secured and monitored in about 90 days

The plan covers one AI system. Each phase ends with a written report and a decision point, so you always know where you stand.

Days 1–14

Assess

We list the AI in an agreed scope, map the data it touches and rank the risks against your rules.

  • AI inventory and data-flow map
  • Risk and gap report
  • Prioritized fix plan with costs
Fixed price

Days 15–60

Secure and test

We build the controls into one AI system, then attack it, fix what gets through and test again.

  • Guardrails, data protection and access controls
  • Red-team test, fixes and re-test
  • Policies, approvals and logging in place
Fixed price

Days 61–90

Operate and prove

We monitor, re-test and keep the evidence current as models, threats and your requirements change.

  • 24/7 monitoring and alerts
  • Scheduled re-testing and monthly reports
  • Evidence pack kept ready for auditors
Monthly managed service

AI we have shipped in regulated industries

Measured after launch, in production.

  • Financial services65%less manual compliance research for a European fintech, on a private model deployed on-premises to meet GDPR requirementsRead the case study
  • Healthcare40%of patient queries automated for a US telehealth provider, with HIPAA standards maintained for patient data and sensitive cases escalated to licensed professionalsRead the case study

Our information security and compliance practice is led by a consultant who holds ISACA’s Certified Information Security Manager (CISM) credential, with hands-on ISO/IEC 27001 experience. See our cybersecurity compliance services.

Questions security and compliance teams ask us

Something else? Ask us on a call.

What is the difference between AI security, AI governance and AI compliance?

Security protects an AI system against attack and misuse. Governance decides who may build and approve AI and how it is watched. Compliance shows that both meet the rules you answer to. They overlap, so we deliver them as one program: one set of controls and one set of tests, with evidence that serves all three.

Can you make our AI HIPAA, GDPR, SOX or PCI DSS compliant?

No, and no vendor can. Compliance is decided by your auditors, regulators and counsel, and it covers how your whole organization operates, not one system. We design each AI system around the requirements that apply, build and test the controls and hand you the test evidence. You remain the regulated entity.

Will our data be used to train AI models?

By default, no provider trains on it. We choose model services whose terms exclude training on customer data, switch retention off where the provider allows it, or host open-source models in your own environment. A model is fine-tuned on your data only when you ask for it. Sensitive fields can be masked before anything reaches a model.

Where is our data stored and processed?

In US cloud regions by default, on AWS, Microsoft Azure or Google Cloud, and inside your own cloud account if you prefer. Where data has to stay in a particular place, the system and its model can run in your own environment, including on-premises. For personal data from the EU or UK, the region and the transfer terms are agreed with you before any data moves.

Can prompt injection be prevented?

Not completely, and we do not claim to. No model resists it reliably and screening catches known attacks, not all of them, so we design for the one that gets through. A model that reads untrusted content can reach only the tools and data its task needs, and high-impact actions wait for a person. We attack the system ourselves before launch and again after significant changes.

How do you control what an AI agent can do?

Each agent gets its own identity, an approved list of tools and credentials that expire. When it works on a person’s behalf it can read only what that person may read. High-impact actions such as payments, deletions or bulk messages to customers wait for a person, and limits are enforced outside the model. Every action is logged, and any agent can be stopped.

We already have SOC 2 or ISO 27001. What is different for AI?

Those programs cover your infrastructure and processes, and they still apply. AI adds risks they were not written for: models that can be steered through their inputs, data that leaks through prompts and logs, and agents that act on their own. We extend your existing controls to cover those and map the result to the NIST AI Risk Management Framework and ISO/IEC 42001. For ISO 27001 or SOC 2 readiness across your whole company, see our cybersecurity compliance services.

Does the EU AI Act apply to a US company?

It can. The Act reaches companies outside the EU that place AI systems on the EU market, or whose AI output is used there. The bans on prohibited practices and the transparency duties already apply, and the high-risk requirements follow in December 2027 and August 2028. We propose a risk class for each use case, with the reasoning, and build the controls that class calls for. Your counsel confirms the class, your role and your obligations.

Can you secure AI we have already built or bought?

Yes. The assessment covers systems that are already live, including third-party assistants and tools your teams adopted on their own. We test them where the vendor’s terms allow it, rank the findings and fix what we can change. For vendor products we list the settings to change and the data-handling terms to raise with the vendor and your counsel.

What will our auditors and customers actually receive?

An evidence pack: the AI inventory and risk register, data-flow maps, a control matrix mapped to each rule, security test reports, the AI bill of materials, change records and audit logs. Under the managed service we keep it current.

What happens when something goes wrong?

Under the managed service we monitor the system 24/7. When an alert fires, the system can be stopped at once and returned to its last approved version, and your AI incident plan names who is told and what happens next. The audit trail shows what the system did. Notifying regulators and the people affected remains your duty; we tell you promptly what happened and give you what the audit trail shows.

How long does it take, and what does it cost?

The AI risk assessment takes about two weeks and is fixed-price. Securing and testing one AI system takes about six weeks, also fixed-price, so you know the cost before you commit. After that, monitoring, re-testing and evidence run as a monthly managed service. If we are also building the system, these controls are part of that build.

Talk through your AI risks in a 30-minute call

Free, with a senior consultant, not a sales script. You’ll leave with:

  • The rules your counsel should check first for your AI use cases
  • The three risks we would fix first
  • What a two-week AI risk assessment would cover for your systems