AI Governance and AI Security: Why You Need Both

That decision needs a shared record. What will the AI do? Which data can it use? What did the tests show? Who owns the risks that remain?

Bring legal judgment, technical evidence, and business responsibility into the same review. Give an authorized owner the decision. Counsel can block on legal noncompliance. The business owner does not override that stop.

Governance directs the work

AI governance sets the purpose, authority, and operating rules for AI. Security supplies controls and technical evidence within that system.

NIST’s AI Risk Management Framework 1.0 treats GOVERN as a cross-cutting function. It runs through MAP, MEASURE, and MANAGE. It covers legal requirements, clear roles, AI inventories, ongoing review, and retirement. It also places responsibility for AI risk decisions with executive leadership. (NIST AI 100-1)

ISO/IEC 42001:2023 takes a management-system approach. It uses Plan–Do–Check–Act to organize how an institution develops, provides, and uses AI. The aim is an operating process that improves over time. (ISO/IEC 42001) ISO packages 42001 as AI governance and 27001 as information security. You need both layers for a complete program. (ISO overview)

Put that structure to work. Assign owners. Define approval conditions. Test controls. Review results. Update the decision when the use changes.

Use AI Governance: Inventory, Risk-Tiering, and Oversight to build the program. This article focuses on the decision that legal, technical, and business owners must reach together.

Connect legal requirements to tested controls

Start with the legal requirement. Then identify the control that supports it.

For confidential information, review the data flow and access controls. For vendor training rights, check the contract and the available settings. For an AI agent, define which tools it can call. Set clear limits on the actions it can take.

Choose technical guidance that fits the system. The OWASP Top 10 for LLM Applications 2026 focuses on applications powered by large language models. It provides attack scenarios and mitigation guidance for developers and security teams. (OWASP LLM Top 10 2026)

Consider an illustrative case. A company approves an AI assistant for internal drafting. The policy allows confidential information in an approved service. Employees access that service through personal accounts.

The review now needs to resolve a concrete question: Do those accounts provide the contractual protections and technical controls the approval assumed?

Counsel and the technical lead should examine the same account type, terms, configuration, and data flow. Record any limits on what the company can inspect or control.

For lawyers using generative AI in client work, ABA Formal Opinion 512 adds specific professional concerns. It addresses competence, confidentiality, client communication, and other duties. It calls for attention to the benefits and risks of the technology used in legal practice. (ABA Formal Opinion 512)

The practical step is clear: connect the legal review to the tool people will actually use.

Connect technical tests to the business use

Build the test plan around the proposed use.

The 2023 NCSC/CISA Guidelines for Secure AI System Development call for security evaluation before release. They also recognize other evaluations, including safety and fairness testing. Those tests sit outside the guide’s cybersecurity scope. They remain part of the broader release decision. (NCSC/CISA guidelines)

A hiring tool makes the distinction concrete.

Consider another illustrative case. Security has tested access controls and data protection for a resume screener. The hiring team now needs evidence that the screener fits the jobs and selection process. Legal needs to assess the applicable employment requirements.

The EEOC’s Employment Tests and Selection Procedures guidance addresses validation and adverse impact. It also explains that employers retain responsibility for their selection procedures when they rely on vendor documentation. (EEOC employment tests guidance)

Disability access deserves its own review. DOJ’s guidance on AI and disability discrimination addresses screening risks and reasonable accommodations. It also addresses employers’ use of third-party hiring technology. (DOJ AI and disability)

Bring the hiring owner, counsel, technical staff, and qualified testing specialists into that review. Examine job relevance, selection outcomes, accessibility, and the accommodation process. Give each finding an owner.

Security testing establishes evidence about security. The employment review establishes evidence about the hiring use. The deployment decision needs both.

Name an owner for each decision

Use the following model as a starting point. Adjust it to the organization and the risk.

Assign named people to the roles. Give each workstream a lead. Define who can approve, who can require changes, and who resolves disagreement. Counsel keeps stop authority on legal noncompliance. Technical leads keep stop authority on unresolved control failures that the approval conditions require.

Decision or workstream	Lead	Required contributors	Evidence in the decision file
Define the use and its limits	Business or product owner	Legal, technical staff, relevant operational experts	Intended use, prohibited uses, human oversight
Identify legal requirements	Legal	Business, privacy, technical specialists	Applicable requirements and required notices
Approve data and vendor arrangements	Data or service owner	Legal, procurement, security	Data map, vendor terms, training rights, verified settings
Implement and test technical controls	Engineering lead	Security, data owners	Configuration evidence, test results, open findings
Validate fitness for the use	Relevant operational owner	Qualified evaluators, legal, technical staff	Validation results, limitations, required safeguards
Authorize deployment	Authorized business decision-maker	Required legal, technical, and operational reviewers	Decision, conditions, remaining risks, review date
Coordinate an incident	Named incident lead	Security, legal, affected business teams	Response plan, preservation steps, notification assignments
Monitor, suspend, and retire the use	Operational owner	Engineering, security, legal as needed	Monitoring thresholds, rollback plan, retirement criteria

For a hiring system, the operational owner may be HR. For a customer-service assistant, it may be the support leader. Choose evaluators with expertise in the actual task.

Keep approval authority explicit. Escalate legal questions to counsel. Escalate technical findings to the responsible technical lead. Give the authorized business owner a clear account of the remaining choices. Do not treat business authorization as a waiver of counsel’s block on legal noncompliance.

Build useful, protected records

Design logging around a purpose.

Record the events needed to detect misuse, investigate incidents, and assess performance. Decide when prompt or response content is necessary. Minimize sensitive content. Restrict access. Set retention periods and assign someone to review alerts.

Build preservation and legal-review procedures into that design. Ask counsel to assess privilege under the applicable law. Keep legal advice and restricted evidence in appropriately controlled files. Creating logs for security also creates an evidence set. Privilege over model cards, bias tests, or security logs is fact-specific.

Treat the decision record as the common point of reference. Link it to supporting material with the right access controls.

Practice the incident handoff. Name the person who can suspend the system. Identify who preserves evidence and who evaluates notification duties. Use Data Incident: The First 48 Hours to support that response.

Put evidence in the working file

The working file should explain the decision and support it.

Describe the approved use. Identify the system, model version where available, configuration, and connected tools. State the purpose, users, data classes, and operating limits. Explain the human review process.

Show the controls and results. Record the legal requirements and vendor terms that shaped the design. Identify the controls tested. Include the test methods, results, and limitations. For a hiring use, include the relevant validation and accommodation review.

Record the decision. Name the approver and required reviewers. State the conditions of approval. Describe the remaining risks and the authorized owner who accepted them. Give open actions an owner and a deadline.

Define the next review. Set a review date. Identify changes that require an earlier review. Include monitoring responsibilities, incident contacts, and suspension or rollback criteria.

Keep the file specific. “Security reviewed” becomes a dated test report. “Legal approved” becomes a defined scope and stated conditions. “Human oversight” becomes a named role with time, information, and authority to act.

The file should show what the teams tested, what remains unresolved, and which use the approval covers.

Match the review to the risk

Set the depth of review by the use, data, system authority, and potential harm.

Keep routine uses within established approval patterns. Give new or materially changed uses the review they need. Apply particular care when a system handles sensitive information, makes consequential recommendations, or takes actions through connected tools.

NIST’s framework supports risk-based review throughout the system’s life. It calls for continued assessment as capabilities, context, and impacts evolve. (NIST AI 100-1)

Use AI Use Intake to identify the proposed use and required reviewers. Start while the team can still change the design. Use the final readiness review to confirm that the required work is complete.

Authorize deployment when the legal requirements and agreed release conditions are met. Record the remaining risks. Give the operational owner clear monitoring and escalation duties.

Then keep the approval current. Revisit it when the model, data, permissions, vendor terms, or intended use changes materially.

Make one accountable decision

At release, the shared record should answer three questions.

What use did we approve? What evidence supports that approval? Who owns the next action?

Legal judgment defines the obligations. Technical work tests the controls. Business ownership turns those findings into an accountable decision.

Governance sets the direction. Security helps make it work. A sound deployment brings both into the same decision.

Use note

This article provides general information for business owners, in-house counsel, and technical leads. Use it as a readiness reference. Obtain legal advice for the specific use and jurisdiction.

Apply each source to its purpose. Management frameworks organize the program. Technical guidance informs controls. Counsel identifies the laws, contracts, and professional duties that govern the use.

Questions: Tom@TomCedoz.com

Primary sources: NIST AI 100-1 (AI RMF 1.0) · ISO/IEC 42001:2023 · ISO 42001 / 27001 packaging · OWASP LLM Top 10 2026 · NCSC/CISA Guidelines for Secure AI System Development · ABA Formal Opinion 512 · EEOC Employment Tests and Selection Procedures · DOJ guidance on AI and disability discrimination