Putting the Forest First

If the perfection trap is the problem, the answer is not to lower the standard. It is to build the system through which the standard can be applied, tested, and improved.

Putting the forest first means establishing the structure within which individual risks can be identified, prioritized, assigned, controlled, and revisited. It does not mean ignoring individual defects. It means having a process capable of finding, prioritizing, and addressing the ones that matter most.

That process depends on visibility and trust. In all but the smallest organizations, legal and governance professionals rely on cross-functional partners to answer a basic question: What are we governing?  Without reliable information about systems, data (and the data's own reliability), vendors, users, and use cases, governance efforts can easily become detached from the environment they are intended to govern.

Trust is equally important, and it is not automatic. Legal and governance teams must account for compliance obligations, operational realities, and organizational priorities. The process should translate legal and organizational requirements into controls that operational teams can implement and governance teams can test.

A documented interim framework with assigned owners, priorities, deadlines, and escalation paths can provide a more defensible basis for action than unmanaged delay, particularly if the organization can show that the framework actually operated. The initial framework need not be complete. It does need to be real.

1. Begin With Purpose and Boundaries

Early governance efforts can become consumed by the search for a complete inventory. Visibility is essential, but governance need not wait for an exhaustive list of every AI-enabled feature, tool, model, and service before addressing known consequential uses.

A more productive starting point is purpose:

• What does the organization want AI to do, and which benefits is it trying to obtain?
• Which uses fall outside its preliminary risk tolerance?
• Which uses require additional review or leadership approval?
• Who has authority to make those decisions?

Beginning with organizational purpose changes the tone of governance. Instead of asking only how to restrict AI, the process first identifies which uses the organization wants to enable responsibly.

From there, leadership and cross-functional stakeholders can establish preliminary boundaries. Those boundaries should reflect legal requirements, operational consequences, contractual commitments, effects on individuals, organizational values, and reputational risk.

For example, an organization may permit AI-assisted customer analysis for defined internal purposes while prohibiting the use or disclosure of the resulting information for unrelated third-party purposes. That boundary may reflect privacy law, contractual commitments, consumer expectations, and the organization’s own risk tolerance.

NIST’s voluntary framework supports an iterative, context-specific approach rather than a universal linear checklist. That flexibility does not eliminate the need for visibility. It permits the organization to begin governing known uses while improving that visibility over time.

2. Build the Decision Structure

Once preliminary purposes and boundaries are established, governance should turn to structure.

The organization should define:

• who receives and initially classifies proposed use cases;
• which matters require legal, privacy, security, compliance, or executive review;
• how AI reviews integrate with procurement and vendor management;
• how internally developed systems enter the process;
• who may approve, restrict, suspend, or reject a use; and
• how exceptions are documented and revisited.

Governance should connect with the ordinary processes through which technology enters and changes within the organization. A stand-alone AI committee will have limited value if procurement can complete a purchase without involving it, vendors can activate new AI features without review, or internal developers can materially alter a system without triggering reassessment.

Diverse participation also helps prevent duplicative or contradictory controls. Legal may identify a statutory requirement. Security may know that the proposed safeguard is technically unavailable. Procurement may know that the vendor has refused the relevant contractual protection. Operations may know that the approval process will be bypassed if it adds three weeks to a two-day decision.

The framework needs a place where those facts can meet.

3. Develop Visibility Through the Process

Governance need not wait for an exhaustive inventory, but known consequential systems should enter the process immediately.

The inventory can then mature through:

• procurement and renewal reviews;
• vendor and contract inventories;
• technical discovery;
• internal development reviews;
• employee reporting;
• business-unit attestations;
• security and privacy assessments; and
• periodic reviews of newly added vendor functionality.

Some missed systems will reappear through procurement or renewal. Others will not. Internally developed tools, free services, shadow AI, embedded vendor features, and automatically updated models may remain outside contractual checkpoints.

The framework therefore needs recurring technical and organizational discovery. The inventory is not a one-time prerequisite to governance. It is one of governance’s continuing products.

4. Assess Risk Proportionately

Risk assessment need not be elaborate at the outset. An organization can begin with a defined set of factors and reserve deeper review for more consequential uses.

Useful factors may include:

• the consequence and reversibility of error;
• the number and nature of individuals potentially affected;
• the system’s level of autonomy;
• the sensitivity of the relevant data;
• external connectivity and available tools;
• reliance on third-party models or services; and
• the degree to which humans can understand, contest, override, or stop the result.

Risk depends on context. A weakness that is tolerable in an internal drafting aid may be unacceptable in a system affecting employment, healthcare, safety, eligibility, financial access, or legal rights. Bias, incomplete data, model drift, prompt injection, inaccurate output, excessive autonomy, and vendor dependency do not present the same consequences in every deployment.

Proportionality allows an organization to direct scarce attention toward uses that can produce consequential or difficult-to-reverse outcomes. It also reduces the likelihood that governance will become a uniform approval ritual in which low-risk and high-risk uses receive equally burdensome and equally shallow review.

5. Monitor Change

Approval is not the end of the process. AI systems change after implementation. Vendors update models, add features, modify terms, and alter subprocessors. Users expand the original purpose. New data enters the workflow. Systems gain access to additional tools or repositories. Scale increases. Human review becomes less meaningful as volume grows.

Governance should therefore establish specific reassessment triggers. Review should occur when a system’s purpose, users, data, model, vendor, autonomy, integrations, scale, or decision authority materially changes. Monitoring results, complaints, incidents, or control failures may also reveal that an original assumption no longer holds.

“Review regularly” is not, by itself, much of a control. The framework should identify what kind of change triggers review, who is expected to recognize it, and who has authority to determine what happens next.

6. Prepare for Failure

Organizations should assume that some AI risks will materialize through system failure, misuse, inaccurate output, external attack, vendor conduct, or unexpected interaction with other systems.

Incident planning should identify:

• escalation thresholds;
• investigation and decision authority;
• documentation expectations;
• internal and external notification responsibilities;
• criteria for suspending or limiting a system;
• procedures for identifying affected outputs or decisions;
• remediation responsibilities; and
• conditions for restoring, replacing, or decommissioning the system.

The process should also distinguish an AI-specific incident from an ordinary privacy, cybersecurity, employment, consumer-protection, technology, or operational incident in which AI happens to be involved. The label should not determine the response structure.

Governance requirements must also reflect realistic assumptions about organizational capability. Overly punitive or impractical rules can encourage avoidance and concealment. A framework that treats every reported mistake as misconduct may receive fewer reports, not fewer mistakes.

Effective incident preparation gives employees a usable route for raising concerns and gives leadership a defined basis for deciding when a system should be restricted or stopped.

From Function to Resilience

Governance programs gain credibility through use. A workable process gives business teams somewhere to bring new ideas, gives reviewers a basis for distinguishing routine uses from consequential ones, and gives leadership evidence about where authority, resources, or controls remain insufficient.

External trust depends in part on whether an organization can provide accurate, timely, and accountable explanations appropriate to the circumstances. That does not require immediate disclosure of every preliminary fact. It requires a process capable of determining what can responsibly be said, by whom, and when.

The practical point is not that any governance framework is better than none. It is that organizations should establish enough structure to govern known consequential uses now: defined boundaries, assigned authority, proportionate review, improving visibility, reassessment triggers, and a credible response when something fails. The framework can mature because it is operating, rather than remaining comprehensive only in aspiration.

The goal is not completeness. It is resilience: a system capable of identifying consequential change, correcting failures, and improving without waiting for uncertainty to disappear.

The instinct to “get one’s hands around it” may remain. In a functioning governance system, it no longer has to mean standing still.

Organizations seeking to move beyond paralysis and toward resilient, functional AI governance do not have to build that system alone. The Jones Walker Privacy, Data Strategy and Artificial Intelligence team advises on AI governance, risk assessment, vendor contracting, incident response, and regulatory compliance. Stay tuned for continued insights from the AI Law and Policy Navigator.