Introducing an AI service into an organization changes its security position in ways that ordinary application risk assessment does not capture. Not because AI is uniquely dangerous, but because these systems combine two properties that most software does not: they are given broad access in order to be useful, and they act on text they receive without a reliable way to distinguish instructions from content.
What follows is the set we work through before a deployment. Most of it is not exotic. The exotic parts are flagged as such, and the ordinary parts are ordinary precisely because they are the ones that actually go wrong.
1. The AI already in use that nobody approved
This is first because it is the most common finding and the only one that is already true rather than prospective.
Staff adopt useful tools quickly. In every assessment we run, some quantity of organizational information has already been entered into a public AI service under terms nobody read, and the organization has no record of what or when. The exposure is not hypothetical and it is not evenly distributed: it concentrates in the teams under the most pressure, which are frequently the ones handling the most sensitive work.
Assess it by asking, without consequence attached. An investigation produces a smaller number that is not true. Then provide an approved alternative, because the usage will not stop, it will only become invisible.
2. The service inherits the permissions of whoever runs it
An AI assistant connected to your systems can reach exactly what the account operating it can reach. If access has accumulated over years, and in most organizations it has, then deployment grants that accumulation to a tool that will use all of it to answer questions.
The failure mode is quiet. Nothing is breached and no alert fires; a user simply asks a reasonable question and receives an answer assembled from material they were never meant to see, presented with the same confidence as anything else. Because there is no unauthorized access event, ordinary monitoring will not show it.
Assess whether access is scoped to what each role needs before connecting anything, and record the review. This is ordinary access management, and it is the highest value item on this page.
3. Sensitive data leaving on the way out
Anything entered into an external service has left your environment. What happens next depends on the supplier's terms, which vary considerably and change.
Assess four things per service, in writing: where content is processed and stored, whether it is used to train models and how that is disabled, what is retained and for how long, and what happens on termination. Read the linked policies rather than the summary, because the substantive answer is usually one document further in than the agreement.
Then decide, in writing, which categories of your information may go to an external service at all. A rule a person can apply without asking is worth more than a policy requiring judgment, because judgment under time pressure defaults to yes.
4. The model can be instructed by the content it reads
This is the genuinely new one, and it is worth understanding rather than taking on trust.
A language model does not reliably distinguish between instructions from its operator and instructions that appear in material it is processing. If your assistant reads incoming email, uploaded documents, web pages or ticket text, then anyone who can get text in front of it can attempt to influence what it does: exfiltrate what it has access to, produce a misleading answer, or take an action it has been given the ability to take.
The formal treatment is in NIST's taxonomy of adversarial machine learning attacks, which names the categories and is readable by a technical audience.
There is no complete defence to this today, so the assessment question is a design question: what could the system do at its worst. A tool that drafts text for a person to review has a low ceiling. A tool authorized to send messages, change records or execute transactions on its own has a high one, and the exposure is the difference between them. Constrain capability rather than relying on the model behaving.
5. Confident wrong answers, treated as findings
These systems produce fluent output that is sometimes incorrect, and fluency is not correlated with accuracy. That is a property of the technology, not a defect awaiting a patch.
Security teams sometimes leave this to the business as a quality issue. It belongs on the risk register, because the damage pattern is a security damage pattern: a wrong answer acted on at scale, quickly, with no audit trail explaining why.
Assess where a wrong answer would do harm before anyone noticed, and put a human between the output and the consequence at exactly those points. Assess also whether the people receiving the output could recognize a wrong answer in their own subject matter, because a review step performed by somebody unable to evaluate the content is not a control.
6. No record of what happened
Most organizations deploying an AI tool cannot answer, afterwards, what was asked, what was returned, what information the answer drew on, or who saw it.
That matters for incident response, where you cannot scope an incident you cannot reconstruct. It matters for public bodies with disclosure and retention obligations. And it matters for the ordinary business of finding out why something went wrong.
Assess what the tool logs, whether those logs are under your control or the supplier's, how long they are kept, and whether anybody would actually review them. Logging nobody reads is a compliance artifact rather than a control, but it is still better than nothing, because it makes reconstruction possible.
7. Identity, and the accounts nobody deprovisions
AI tools are frequently adopted departmentally, with their own account lists, outside whatever central identity arrangement the organization has.
The consequence arrives at offboarding. A leaver removed from the directory retains access to a tool that was never connected to it, and the tool has access to organizational information. This is not new, but AI tools are adopted faster and more locally than most software, so the gap opens more often.
Assess whether the service can be connected to your identity provider, and treat inability to do so as a real cost rather than an inconvenience.
8. Supply chain, including the parts you did not choose
An AI feature in a product you already own is a supply chain question you may not have been asked to consider. Vendors add these capabilities to existing platforms, sometimes enabled by default, and the data flow can change without a procurement event.
Assess which of your existing suppliers have added AI features, whether those are on, what they send where, and whether you were notified. Add a term to renewals requiring notice of material changes to how your data is processed. This is the risk most likely to arrive without anybody deciding anything.
9. Availability, and what happens when it is not there
Once a tool is embedded in a process, its outage becomes your outage. External AI services have degraded performance and rate limits, and models are deprecated and replaced on the supplier's schedule rather than yours.
Assess what the process does when the service is unavailable, and whether staff retain the ability to do the work manually. A team that has lost the underlying skill has converted a supplier outage into a service failure.
Assess also what a model change would mean. Output that was reliable can shift when a supplier updates the model, which is a change management problem with no change control ticket attached.
10. Cost as an availability risk
Usage-based pricing means an unbounded process, a loop, or simple enthusiastic adoption can produce a bill that forces an emergency shutdown. That is an availability incident with a financial cause.
Assess whether spending limits and alerts exist, and who is notified.
Where these sit in a readiness assessment
Cybersecurity and privacy is one of the seven dimensions of AI readiness, and it is the one where a low score most often reflects an exposure that already exists rather than a capability that is missing.
This page is a risk list rather than a control framework. The NIST Cybersecurity Framework and the NIST AI Risk Management Framework are the structures most organizations are expected to be able to reference, and CISA publishes guidance oriented to government and critical infrastructure. All are voluntary guidance: working through them does not make an organization compliant with any statute or contract, and nothing on this page should be read as saying otherwise or as a substitute for a qualified security assessment.
What to do with this list
Work through it before deployment rather than after, and record the answers even where the answer is that you accept the risk. An accepted risk with a name and an owner is a decision; an unexamined one is an accident waiting for an audience.
To see where security sits relative to your other dimensions, the AI Readiness Self-Assessment scores all seven in about eight minutes, and the public-sector readiness checklist turns them into items you can assign. Governance decisions that follow from this list are covered in an AI governance framework for public-sector organizations.
Where an organization wants this examined properly rather than self-assessed, the readiness assessment we run covers the security dimension alongside the other six. LABUSA also provides cybersecurity services where the finding is that the underlying position needs work first, which it frequently is. Tell us what you are planning to deploy and we will tell you what we would look at.