AI security & risk · the framework
AI damage comes through two doors: the internal one, which governance covers, and the external one, which security covers. identifiable's AI Risk SOLN framework protects both, layer by layer.
In short: AI governance covers internally caused damage, most often unintentional: bad usage, bad models, unauthorized instances, misalignment. AI security covers externally caused, intentional damage: a person or entity attacking the system. identifiable handles both with the AI Risk SOLN framework, from use-case discovery to system lockdown.
Internal · governance
The wrong model chosen, the wrong data source, training done badly: the ingredients were not the right ones, and the result harms without anyone intending it. Add system misalignment, policy violations, ethical lapses, and shadow AI: an AI instance created without approval, running somewhere, able to leak data. Governance exists so this unintentional damage does not happen.
External · security
A person or an entity attacks the system, intentionally: prompt injection, poisoned data, unauthorized access, exfiltration, denial of service. Security exists so the system withstands it: prevent, detect, respond, and know how to exit (exit strategy, data deletion and accessibility).
That the AI representing your organization does it in a way you would approve of. Point by point:
The system does not make things up. What it states is reliable, documented, attributed to its sources, and traceable end to end. Documentation and source attribution are what make an answer trustworthy.
The model is fair and unbiased, and it stays consistent over time: drift (answering well at first, then hallucinating) is monitored through indicators. Model integrity is verified, never presumed.
No one accesses your intellectual property through the model, and your model is not trained on intellectual property it has no authority to use. Both directions are verified.
Hate, abuse, profanity: HAP filtering is tested, particularly in HR uses where one misplaced output exposes the organization and the people involved. Resume screening is governed like a decision, because it is one.
When the system or the model comes from a third party: what governance and security measures does it already carry? identifiable's qualification grid asks the question before adoption, never after the incident.
Rules, policies, applied policies with follow-up, accountability structures. A policy written but not applied caps out in the AIiD profile: observed application is what counts.
Three guarantees, inherited from information security and reapplied to AI systems:
C
The model does not exfiltrate. No confidential information leaves the company's systems through an answer, a log, a connector, or third-party training.
I
The system cannot be manipulated. No entity should be able to make it do anything other than what you approved: prompt injection, poisoned data, and hijacks are tested and blocked.
A
The system stays up. A denial-of-service attack must not deprive your teams, your clients, or your workflows of the system they depend on.
The measures follow the full cycle: prevention (guardrails, access, hardening), detection (threat and behaviour monitoring), response (incident procedure, containment), and exit strategy (reversibility, data deletion, accessibility of what belongs to you).
The model is trained properly, and its lineage can be traced: for an internal model, where the foundational data comes from, who touched it, which code, which versions, which sources. Without lineage, no demonstrable integrity.
What your AI is allowed to do, where its limits stop, and what your risk tolerance is. Decided in writing with leadership, enforced in the guardrails, measured in the AIiD profile.
Models are tested: penetration testing, model scanning to verify they are not infected, protection against prompt injection and unauthorized access. identifiable provides tools for automated prompt-injection testing.
IP risks are mapped in both directions: exposure of your IP through the model, and usage rights over the data that trained it. Both belong in the risk register.
The AI Risk SOLN framework
Three layers of protection: the model, governance, security. And a six-move path, fully tooled.
01
Discovery and management of AI use cases, including shadow AI: the instances in service, the models in use, declared or not. You lock down what you have first found.
02
Model and lifecycle management: an AI system starts, matures, then parts of it vanish and other parts evolve. Every stage is governed, from commissioning to retirement.
03
Risks are quantified, mapped, and addressed. Where full quantification is out of reach, they are at least exposed and mapped: every risk has an owner, a measure, and a date.
04
Threat monitoring and performance control: drift, off-policy behaviour, incidents. All of it visualized, so leadership sees what the teams see.
05
Compliance and due diligence specific to your sector: what an insurer, a prime contractor, or a regulator requires differs by industry, and diligence is calibrated accordingly.
06
AI security posture management (AISPM): keeping configurations aligned with the security policy, locking down what must be locked down, and proving it continuously.
The framework's tooling: an AI gateway (guardrails, exfiltration blocking), threat monitoring, penetration testing and model scanning, automated prompt-injection testing, and dashboards that make the whole thing visible. The tools serve the framework; the framework serves the decision.
Governance covers the internal side: bad usage, bad models, unauthorized instances, misalignment, policy or ethics violations. The damage is most often unintentional. Security covers the external side: a person or entity attacking the system, intentionally. The two layers are installed separately and measured separately.
An AI instance created or used without approval: a personal account wired to company data, an agent built over a weekend, a SaaS tool with embedded AI no one qualified. Every undeclared instance is a potential leak. You discover it, qualify it, lock it down, or retire it.
Yes, and it is the most common case. Due diligence then focuses on the governance and security measures the third-party system or model already carries, on the residence and use of your data, and on reversibility: exit strategy, data deletion, accessibility of what belongs to you.
The AI Risk SOLN framework operationalizes what the NIST AI RMF asks (govern, map, measure, manage) and what Law 25 requires as soon as personal information enters an AI tool. The AIiD evaluation measures the posture against the AI id framework; the framework installs the protections.
Read next: the AIiD program, the system and agent evaluation · the NIST AI RMF, explained without jargon · Law 25 for those who use AI · all services
The AI risk is already inside your systems. The thirty-minute discovery call tells you where to start.