Imagine you’re a managing partner evaluating a new AI research tool that promises to cut document review time by 60%. The vendor proudly displays their SOC 2 Type II badge and ISO 27001 certification. You’ve done your due diligence and found no red flags in their SOC 2 report or ISO 27001 audit. You’re ready to deploy.
Three months later, opposing counsel in a high-stakes litigation subpoenas the vendor’s training logs. Buried in those logs are summaries of privileged strategy memos your associates entered into the tool’s “learning mode.” The certification you relied on never tested whether the vendor’s AI could reconstruct confidential inputs from model outputs. It only verified that the vendor’s policies existed.
This is the real gap between what traditional security certifications promise and what legal practice requires.
New frameworks like ISO/IEC 42001 and NIST AI Risk Management Framework claim to address AI-specific risks. But do they actually cover what law firms need: privilege protection, ethical walls, and the explainability required when your work product is challenged in court?
For law firms, the inadequacies of traditional certifications are compounded by professional ethical obligations. ABA Formal Opinion 512 and various state bar guidelines clarify that the duty of confidentiality (Rule 1.6) and competence (Rule 1.1) apply with heightened rigor to AI usage.
Privilege preservation and the “self-learning” trap
Attorney-client privilege depends on a reasonable expectation of confidentiality. Many AI platforms are “self-learning,” meaning that they use user inputs as feedback to improve the global model. If a lawyer inputs case strategy into a self-learning tool, they may be deemed to have waived the privilege because the data is no longer confidential once it has been shared for the provider’s commercial improvement. Traditional SOC 2 reports do not certify the legal status of data; they certify its confidentiality according to the vendor’s own policy, which may explicitly allow for this kind of improvement use.
The failure of ethical walls in AI assistants
Traditional law firm security is built on “Ethical Walls” that prevent attorneys on adverse matters from seeing each other’s data. When a firm integrates an AI tool (like Harvey or CoCounsel) with their Document Management System (DMS), they often create a “Matter-Blind” point of failure. If the AI assistant has access to the entire firm repository to “provide better insights,” an attorney on Matter A could theoretically use the AI to retrieve summaries or strategies derived from documents in Matter B. Standard SOC 2 audits check for access controls at the system level but do not conduct the multi-tenant or multi-matter semantic testing needed to ensure ethical wall integrity.
The certification tells you the vendor has a management system, but doesn’t tell you whether the system accounts for the specific ethical obligations you face in the jurisdiction where you practice.
Explainability and the audit trail for work product
Lawyers remain fully accountable for all work product, regardless of how it is generated. Traditional security certifications verify that an “audit log” exists for system access, but they do not require an “explainability trail” for AI reasoning. If a lawyer uses an AI-generated chronology for a deposition, and that chronology is based on hallucinated documents, the SOC 2 report provides no recourse. The industry needs integrity frameworks that document the specific sources and reasoning steps the AI took to produce a legal work product.
Emerging AI-specific frameworks
In response to these gaps, new frameworks have emerged that specifically target AI governance. Evaluating whether these frameworks are substantive or merely security theater is critical for legal teams looking to deploy AI responsibly.
ISO/IEC 42001: The Artificial Intelligence Management System
ISO 42001 is the world’s first certifiable standard for governing the entire AI lifecycle, an AI-focused relative of ISO 27001. Unlike ISO 27001, which focuses on security, ISO 42001 requires an organization to establish an AI Management System (AIMS) analogous to an Information Security Management System (ISMS). It introduces controls you won’t find in ISO 27001: transparency requirements so users can understand why a model made a recommendation, mandatory bias testing, human-in-the-loop mechanisms for high-risk decisions, and documentation of where training data came from and how it was used.
For law firms evaluating ISO 42001-certified vendors, these controls directly tackle many blind spots, but not all of them. It requires policies for ensuring quality and handling of training data, risk assessments for model misuse or failures, and internal audits of AI systems. If a vendor adopts ISO 42001, they would be forced to address questions like “how do we prevent unauthorized use of client data in model training?” and “do we have an escalation if AI output seems erroneous or biased?” However, like any ISO standard, it has the potential to be abused, becoming a paperwork exercise rather than a pragmatic AI governance pursuit. The standard’s novelty may work in its favor: auditors for ISO 42001 might be more specialized, and companies pursuing it are more likely to treat it seriously.
NIST AI Risk Management Framework (AI RMF)
While not exactly a certification, the NIST AI RMF provides a non-prescriptive but highly detailed approach to managing AI-specific risks. It can serve as a benchmark for responsible AI due diligence in the legal industry when vetting vendors. It introduces functions like map, measure, manage, and govern, addressing categories such as data privacy, safety, security, robustness, bias, and explainability. For example, it calls out risks of model bias and encourages measures to mitigate data poisoning and adversarial attacks as part of “secure and resilient AI” practices.
The AI RMF does not replace standard certifications like ISO and SOC 2. Rather, it provides a detailed overlay for organizations to identify and control AI-specific risks. It serves as a toolkit to ensure trustworthy AI, emphasizing things like transparency (e.g., being able to interpret or explain model decisions), continuous monitoring of AI performance, and supply chain security for AI components.
If widely embraced, NIST’s framework could fill many gaps. It prompts organizations to think about the issues we have discussed in prior posts, e.g., have you addressed the possibility of model extraction or poisoning? Do you have human oversight when needed? Are you tracking if the model’s accuracy is degrading? These are questions that a SOC 2 or ISO audit wouldn’t ask, but NIST RMF explicitly encourages. The challenge, however, is that AI RMF is guidance, not a certification. As such, it is only as good as the effort a company puts in it, and only works if it is accompanied by real changes to ensure alignment with the NIST AI principles, rather than simply paying lip service to it. Fortunately, regulators like the U.S. FTC have signaled that they expect organizations to follow such best practices. So, adopting NIST AI RMF could be seen as a step toward meeting a duty of care in using AI.
Regional Frameworks and Industry Guidelines
Specific regions, like Europe, are moving to formal regulation. The EU AI Act creates a compliance regime for AI, especially “high-risk” systems, which could include AI used in legal decision-making, hiring, etc. The Act will require conformity assessments and certification for high-risk AI systems, similar to how medical devices are certified. The Act requires a quality management system for AI, risk management process, data governance, transparency to users, human oversight provisions, and robustness and cybersecurity requirements. The Act mandates that providers assess and mitigate “foreseeable vulnerabilities” such as data poisoning, adversarial inputs, and model extraction attacks.
AI tools used for purely administrative tasks likely won’t qualify as “high-risk,” but tools that assist in legal research, case analysis, or decision-making could well fall under Annex III’s “administration of justice” category, which carries the Act’s strictest requirements. Companies will have to keep technical documentation and logs to show regulators how the AI was built and how it is performing, including maintaining an audit trail of AI decisions and data inputs/outputs. The AI Act also forces clear user instructions and disclosures for AI systems, and if an AI is interacting with people, they likely need to know it’s an AI.
Various industry bodies are also issuing AI risk guidelines. For example, the U.S. ABA (American Bar Association) has put out ethics opinions on lawyers’ use of AI, emphasizing duties of confidentiality and competence (meaning you must understand the tech enough to use it safely). Although they don’t provide technical controls, they reinforce that from a legal ethics perspective, using an AI that might leak privilege or give unreliable results without safeguards could violate professional obligations. Organizations like the Cloud Security Alliance (CSA) have released papers on “securing AI workflows,” and OWASP (Open Worldwide Application Security Project) started an AI Security Project. These often provide checklists that can sharpen your understanding of AI risk.
What Even the New AI Compliance Frameworks Miss
These emerging frameworks represent genuine progress. ISO 42001 forces vendors to document their AI risk management. NIST AI RMF provides a vocabulary for discussing AI-specific threats. The EU AI Act will eventually mandate conformity assessments for high-risk systems. But AI compliance frameworks weren’t designed with legal practice in mind, and that creates four significant blind spots.
Privilege is Not Just “Confidentiality”
ISO 42001 and NIST AI RMF treat data protection as binary: information is either confidential or it isn’t. But attorney-client privilege has its own doctrinal requirements: intent, reasonable expectation of privacy, and the context of seeking legal advice. A vendor could satisfy every ISO 42001 control for “data confidentiality” while still having data-handling practices that waive privilege under your jurisdiction’s bar rules. When the framework asks “is this data protected?”, it doesn’t ask “is this data protected in a way that preserves the legal privilege attaching to it?” That’s a question only you can answer, and only if you understand exactly how the vendor processes your inputs.
Matter-Level Segregation is Not Multi-Tenant Security
These frameworks address multi-tenancy (keeping Client A’s data separate from Client B’s data across different organizations), but they don’t contemplate ethical walls within a single organization. A law firm running adverse matters needs assurances that the AI assistant on Matter A cannot surface insights derived from documents in Matter B, even if both matters belong to the same firm. ISO 42001’s access controls operate at the system and organizational level, not at the matter level. You could have a vendor certified to both ISO 27001 and ISO 42001 that still allows cross-matter semantic leakage because the standards simply don’t contemplate this use case.
Human-in-the-Loop is Not the Same as Competent Oversight
Both ISO 42001 and NIST AI RMF emphasize human oversight mechanisms, and the EU AI Act mandates them for high-risk systems. But for legal work product, the question isn’t just whether a human is reviewing, but whether that human has the competence and authority to take professional responsibility for the output. ABA Formal Opinion 512 requires lawyers to understand the benefits and risks of AI technologies they use. A vendor can check the “human oversight” box by requiring a click-through approval screen. That satisfies the framework, but doesn’t satisfy Rule 1.1 if the reviewing attorney has no way to understand how the AI reached its conclusion or whether it hallucinated the case law it cited.
Privilege Rules are Jurisdictional, While Certifications are Not
A vendor certified under ISO 42001 by a European certification body has demonstrated compliance with an international standard. But privilege waiver rules vary dramatically by jurisdiction. What constitutes “reasonable efforts” to maintain confidentiality under California State Bar rules may not satisfy New York’s requirements, and neither may align with UK or EU standards for legal professional privilege. The certification tells you the vendor has a management system, but doesn’t tell you whether the system accounts for the specific ethical obligations you face in the jurisdiction where you practice.
Ultimately, you can’t solely rely on legacy security certifications for protecting the privacy of your AI deployment. Effective AI vendor due diligence for legal practice requires more than accepting certifications at face value. Prioritize vendors who hold ISO/IEC 42001 or those who can demonstrate alignment with NIST AI RMF. You need to verify the scope of the SOC 2 compliance. Beyond accepting a “SOC 2 Type II” badge, you need to read the System Description and Test Controls to ensure the AI inference engine and vector database were actually audited. You need to perform internal AI “red teaming,” in which you conduct periodic tests where a dedicated “offensive” team tries to bypass ethical walls or extract matter-sensitive data via your firm’s own AI tools. You must ascertain that your deployments remain human-in-the-loop, ensuring that your vendors can provide proof of competent human oversight mechanisms.
Even the frameworks explicitly designed for AI weren’t designed for legal AI. Until they are, the burden of due diligence remains on you.
Before signing your next AI vendor contract, ask for their ISO 42001 certification scope and their NIST AI RMF alignment documentation. Read the actual audit reports, not just the badges. And if they can’t answer how their tool handles matter-level segregation or privilege preservation, walk away, no matter how impressive their compliance certificates look.
In my previous post on certification risks, I argued that SOC 2 and ISO 27001 weren’t designed for AI. The uncomfortable truth is that even the frameworks explicitly designed for AI weren’t designed for legal AI.
Don’t accept “we treat all data as confidential” as sufficient. Ask: “If I input privileged strategy memos, can those inputs ever be reconstructed from model outputs, training feedback, or system logs?” If the vendor integrates with your DMS, ask how they enforce ethical walls at the matter level (get this in writing as a contractual representation). If the vendor claims human-in-the-loop capabilities, ask: “What information does the human reviewer see? Can they trace the AI’s reasoning to specific source documents? Or are they just approving a black-box output?”