Is Your Company AI-Ready?
A field guide to scoping AI security investment around data value, regulatory exposure, and legal risk.
Every organization adopting AI eventually asks the same question: are we exposing ourselves to risk we don’t understand? The instinct is to reach for a tool – a DLP policy, a CASB tool, an encryption product – before anyone has answered a more basic question: what data do we have, how sensitive is it, and what is it actually worth protecting?
That’s the gap an AI Risk Assessment closes. Before recommending a single security control, we need to understand two things: how sensitive an organization’s data is, and how valuable it is to the business. Those aren’t the same question – a dataset can be highly sensitive and low value, or moderately sensitive and central to a company’s competitive position. The controls that make sense, and the budget that’s justified, depend on getting that distinction right before any technology decision gets made.
Starting With Understanding your Goals and Objectives
Our AI Risk Assessment begins with a structured method and questionnaire. The goal is to understand what sensitive data the client holds, why it needs protection, and what regulatory obligations attach to it – HIPAA for a healthcare client, GLBA and SR 11-7 for a bank, the NAIC Model Bulletin for an insurer, FDA 21 CFR Part 11 for a pharmaceutical company. Each regime defines sensitive data differently, so the assessment establishes that context first.
This is also where we surface how the business intends to use AI. Piloting Microsoft Copilot against a SharePoint environment carries a different risk profile than building a custom RAG application on customer records, which differs again from fine-tuning a proprietary model on internal research data. The controls that matter shift across those scenarios.
Value Drives the Control Decision
The principle that anchors the assessment: it only makes sense to spend money on a security control if the value of what you’re protecting justifies the cost. That sounds obvious, but it’s the step most security conversations skip. Vendors are happy to sell encryption, masking, and monitoring tools regardless of whether the underlying data warrants that investment. Our job is to size the control to the value of the asset, not to recommend the most sophisticated product available.
That means the assessment produces a value-and-sensitivity map of the data before it produces a single control recommendation. Once that map exists, the right next steps follow a consistent sequence.
The Foundational Layer: Access Control
The first control we recommend, almost without exception, is access governance over AI tools themselves. This provides a clear answer to which AI applications employees may use, and which they may not. This sounds basic, but most organizations don’t have an answer, which means there’s no enforcement mechanism behind it either.
We typically recommend a CASB or network-based DLP policy to enforce that boundary: block or limit unsanctioned consumer AI applications, and channel usage toward a sanctioned, enterprise-governed alternative. This is the cheapest, fastest control to deploy, and it closes the most common leakage path – an employee coping and pasting sensitive information into a free-tier AI chatbot with no enterprise data agreement in place.
Knowing What You Have: Discovery and Classification
The second recommendation is a data discovery, classification, and tagging initiative. This control answers the question the assessment started with: who has access to what data, and how sensitive is it? Without this, every other control is a guess. You can’t write a meaningful DLP policy, scope a RAG knowledge base safely, or apply the right masking rules if you don’t know where your sensitive data lives or who can reach it.
This step routinely surfaces problems nobody knew existed – stale permissions, sensitive records in forgotten folders, departments with broader access than their job requires (over permissions). Fixing that exposure matters on its own. It becomes essential the moment an organization points an AI tool at its document estate, because the AI will faithfully retrieve whatever it’s permitted to see, including what was overexposed by accident.
When the Organization Is Building, Not Just Using
If an organization’s ambitions go further – building its own machine learning or AI systems rather than just adopting AI tools – the control set needs to get more granular. At that point we look at AI prompt monitoring and other runtime controls: visibility into what’s actually sent to and returned from the model, not just whether the application itself is sanctioned.
Email and web DLP tools extend that protection to other exfiltration paths, and inline, agent-based DLP solutions add a further layer by monitoring all outbound traffic and controlling what can be uploaded to a public AI chatbot. These are the controls that matter once an organization moves from “are our employees using AI safely” to “are we building AI systems that handle our own data responsibly.”
What Legal Wants to Know Before They’ll Sign Off
There’s a sixth stakeholder in every AI Risk Assessment who isn’t satisfied by access controls or data classification alone: legal. General Counsel and the legal department are asking a different set of questions than the CISO or compliance team, and an assessment that skips them produces a security program that still can’t get budget approval.
The first question is liability allocation: if the AI gives a wrong answer that causes harm, who is responsible – the company, the AI vendor, or both? Courts have not settled this for autonomous AI agents acting on a company’s behalf, and vendor contracts vary widely on indemnification. Legal needs to know whether the contract for the AI tool actually covers the company if its output causes a loss.
The second is data ownership and IP. Who owns the output an AI model generates from company data? Does feeding proprietary information into a third-party model risk losing trade secret protection, since trade secret law requires reasonable efforts to keep the information confidential? Legal also wants assurance that AI-generated content doesn’t infringe someone else’s copyright, given that several major copyright cases against AI vendors are still working through the courts.
The third is regulatory exposure across jurisdictions. The EU AI Act’s high-risk provisions are now in force, with penalties reaching into the tens of millions. Several states have their own AI laws on the books or taking effect this year, covering employment decisions, consumer disclosures, and risk assessments. Legal needs a clear answer on which of these apply to the company’s specific AI use cases, because the requirements are not the same everywhere.
The fourth is human oversight and the duty to verify. Courts have sanctioned attorneys and, by extension, the organizations they represent for relying on hallucinated AI output without checking it. That same exposure extends to any business decision – a contract, an HR action, a customer communication – built on unverified AI output. Legal will ask whether a human reviews AI output before it’s relied upon, and whether that review is documented.
The fifth is anti-discrimination liability. If an AI tool is used in hiring, lending, or any decision affecting a protected class, existing civil rights and employment law still applies in full, regardless of whether the decision was made by software. Legal wants proof that the organization tested for disparate impact before deployment, not after a complaint.
These legal questions don’t replace the data security work – they sit alongside it. A clean access control policy and a well-classified dataset still leave the company exposed if the underlying contract has no indemnification clause, or if nobody can say whether a human reviewed the AI’s output before it reached a customer. Folding legal’s questions into the AI Risk Assessment from the start means the resulting program can actually clear sign-off, rather than getting flagged six months later when legal finally gets a look at it.
The Point of All of This
None of these controls – access governance, data classification, prompt monitoring, DLP, legal sign-off – exist for their own sake. They exist to protect a company’s intellectual property and non-public data from ending up inside an AI system that wasn’t built with that data’s sensitivity, value, or legal exposure in mind. An AI Risk Assessment is the discipline of figuring out, before any technology gets deployed, what that data is worth, what protection it deserves, and what liability the company is accepting by using it. Get that sequencing right, and the rest of the AI security program follows logically. Skip it, and you end up buying expensive controls for low-value data while leaving the things that actually matter – including your legal exposure – unaddressed.
Book a complimentary 45-minute AI Risk Assessment. We’ll map your data’s sensitivity and value, the regulations that apply, and the controls that actually make sense.
