If a regulated team treats AI approval as a one-time purchasing decision, it will miss the real risk: what data the tool can reach, what actions it can take, and who is accountable when it changes. Datapath recommends a repeatable approval workflow that records purpose, data boundaries, controls, testing, and ongoing ownership.
At 2:17 p.m. in a Modesto public-safety dispatch center, a supervisor opens a vendor demo for an AI assistant that promises to summarize CAD notes and draft incident narratives. The tool can connect to the department’s Microsoft 365 tenant and accept uploaded call transcripts. The sales engineer says the setup takes ten minutes.
That is exactly when the approval decision should happen—not after the assistant is connected, and not when an auditor asks who approved it.
The supervisor needs to answer three operational questions before anyone uploads a dispatch record:
- Can the tool receive criminal justice information, personally identifiable information, or both?
- Can the vendor retain prompts, use them for model improvement, or allow support personnel to access them?
- Does the assistant only draft text, or can it send messages, alter records, or trigger a downstream workflow?
Those questions turn “Should we buy this AI tool?” into the decision that matters: “Under what conditions may this tool operate in our environment?”
For a regulated team, that is the difference between an AI policy that sits in a file share and an approval workflow that protects uptime, accountability, and the organization’s ability to explain a decision.
Why ordinary software procurement is not enough
Traditional application review usually asks whether the vendor is reputable, the price fits the budget, and the application integrates with existing systems. AI adds another layer: the system may generate unpredictable outputs, change as the underlying model changes, and make use of information that users paste into a prompt or expose through an integration.
The approval record therefore needs to capture the complete operating context:
- The business purpose. What work is the team trying to improve? For example, drafting a nonfinal summary of a dispatch call, routing a patient message, or helping accounts-payable staff identify duplicate invoices.
- The data path. What enters the tool, where it is processed, where it is stored, and who can retrieve it later?
- The authority path. Which user, service account, API token, or connected application gives the AI access?
- The action path. Does the tool recommend, draft, classify, retrieve, send, approve, or change a record?
- The exit path. How is access revoked, data deleted, and the tool disabled if it fails or the vendor changes its terms?
NIST’s AI Risk Management Framework organizes AI risk work around Govern, Map, Measure, and Manage, including inventorying AI systems, documenting human oversight, testing before deployment, and monitoring systems in production.1 That maps well to a practical approval process—but the workflow should be adapted to the way each regulated team actually operates.
What should an AI approval request contain?
A request should be short enough that employees will use it and detailed enough that security, legal, compliance, and operations can make a real decision. We recommend treating it like a change request with a required data-flow record.
The minimum approval packet
Require the requestor to provide:
- Named owner: one person accountable for the use case after launch.
- Business process: the exact workflow, such as CAD narrative drafting, EHR message triage, student-support correspondence, or wire-fraud review.
- User population: departments, job roles, locations, and whether contractors or third parties will use it.
- Input classification: public, internal, confidential, regulated, or restricted data.
- Output destination: email, ticketing system, EHR, records-management system, case file, finance platform, or human review queue.
- Integration scope: Microsoft 365, SharePoint, OneDrive, CRM, EHR, CAD, ERP, file shares, or other connected systems.
- Vendor controls: encryption, retention, training use, subprocessors, administrative access, audit logging, incident notification, and deletion options.
- Human checkpoint: the person who reviews the output before it becomes a communication, decision, or official record.
- Fallback procedure: what staff do when the service is unavailable, produces an unsafe result, or must be disconnected.
- Review date: when the owner must confirm that the use case, permissions, vendor, and controls remain unchanged.
The request should also include a plain-language “prohibited use” field. For example: “This assistant may draft a narrative from approved, de-identified text. It may not receive live CJI, make a probable-cause determination, send an external message, or write directly to the records-management system.”
That sentence is more useful than a general instruction to “use AI responsibly.”
A four-gate workflow that works in the real environment
Gate 1: Define the use case before evaluating the vendor
Start with the process owner, not the vendor’s feature list. Ask what task is being performed today, how much time it consumes, and what failure would look like.
For a Modesto dispatch operation, the proposed use case might be “draft a supervisor-reviewable summary from a completed call transcript.” That is materially different from “analyze live calls and recommend a response.” The first may be an administrative drafting aid. The second could affect public safety decisions and requires a much higher level of review.
Record a measurable decision boundary. A useful example is:
The tool may draft text for human review. It may not make an eligibility, treatment, disciplinary, investigative, or financial approval decision, and it may not autonomously send or modify an official record.
If the vendor cannot support that boundary technically, the request should stop at Gate 1.
Gate 2: Map data, identity, and permissions
This is where many “approved” tools become unsafe. A tool may not need a large data set to create a large exposure; one delegated mailbox, shared drive, or overly broad OAuth permission can be enough.
For each proposed connection, document:
| Approval question | Evidence to collect | Decision consequence |
|---|---|---|
| What data enters the tool? | Sample fields, file types, screenshots, classification | Prohibit regulated data unless controls and contract support it |
| Where is data processed and retained? | Vendor architecture, retention settings, subprocessor list | Escalate if location, retention, or deletion is unclear |
| What can the integration read? | OAuth scopes, service-account permissions, API documentation | Reduce permissions to the smallest workable set |
| What can the tool do? | Action catalog, workflow permissions, admin settings | Require human approval for messages, record changes, or transactions |
| What can be logged? | User activity, prompts, outputs, administrator actions | Require logs that support investigation and review |
| What happens when it fails? | Disconnect procedure, export options, manual fallback | Do not approve without an operational fallback |
Healthcare organizations should be especially precise about whether a proposed AI service will create, receive, maintain, or transmit electronic protected health information. HHS states that a cloud service handling ePHI can be used when the covered entity or business associate has an appropriate business associate agreement and conducts its own risk analysis; the parties also need to address safeguards and responsibilities.2
That means “the vendor says it is HIPAA compliant” is not an approval decision. The record should identify the data, the service, the agreement, the risk analysis, and the controls the healthcare organization is responsible for configuring. Datapath’s healthcare and clinic IT team can help connect that review to identity, endpoint, Microsoft 365, and incident-response controls.
Gate 3: Test the tool in a controlled environment
Do not approve an AI tool because its demonstration was impressive. Test it against the organization’s actual failure modes.
A controlled evaluation should use synthetic, redacted, or otherwise approved test data. Give the tool examples that probe for:
- fabricated facts or citations;
- incorrect names, dates, or account numbers;
- disclosure of information from another user or workspace;
- prompt injection through an uploaded document;
- unsafe or biased recommendations;
- failure to preserve required context;
- unauthorized tool calls or record changes; and
- behavior when the service, integration, or identity provider is unavailable.
Set a pass/fail threshold before testing. For example, a drafting assistant may be allowed to produce a rough first draft, but it must never be allowed to send the draft externally or write to the official system of record without human approval. A finance assistant may identify invoices for review, but it cannot release a wire.
NIST’s framework says AI systems should be tested before deployment and regularly while operating, with results documented and functionality monitored in production.1 That supports a simple operating rule: approval is conditional on test evidence, not permanent because a committee once signed a form.
CISA likewise emphasizes that security should be built into technology rather than treated as an optional add-on, highlighting controls such as multifactor authentication, logging, and single sign-on.3 During testing, ask whether those controls are available, enabled, and included in the product tier under consideration—not merely listed on a roadmap.
Gate 4: Approve, restrict, or reject with a named owner
The final decision should be one of four outcomes:
- Approved: the use case and integrations may proceed within documented boundaries.
- Approved with restrictions: only certain users, data classes, environments, or actions are allowed.
- Pilot only: the tool may operate for a defined evaluation period with synthetic or redacted data.
- Rejected: the vendor cannot meet the minimum data, identity, contract, logging, or operational requirements.
Every approval should name three different responsibilities when possible:
- Business owner: accountable for the usefulness and human review process.
- Security or IT owner: accountable for identity, configuration, logging, access, and technical controls.
- Compliance or privacy owner: accountable for regulatory interpretation, records, contracts, and escalation.
For smaller organizations, one person may hold more than one role. The important point is that “the department” is not an accountable owner.
How should regulated teams tailor the workflow?
Public safety and CJIS environments
For a county or municipal public-safety team, treat any connection to CAD, RMS, dispatch recordings, criminal-history information, or investigative files as a high-scrutiny request. The FBI’s CJIS Security Policy v5.9.5 includes requirements and guidance covering access control, audit and accountability, logging, cloud scenarios, and protection of criminal justice information.4
A practical approval rule is to keep an AI assistant outside the CJI boundary unless the agency has documented exactly how the service, personnel, cloud environment, encryption, access, and audit obligations are handled. Start with a redacted export or synthetic scenario. Require the supervisor to approve every generated narrative before it becomes part of an official record.
Datapath’s CJIS compliance and local government and public safety teams can help turn that boundary into identity policy, vendor review, logging, and incident-response requirements.
Healthcare and clinics
For an EHR-adjacent tool, distinguish between administrative convenience and clinical influence. A tool that drafts a patient-message response still needs review for accuracy, privacy, and tone. A tool that prioritizes referrals, summarizes clinical records, or recommends treatment deserves a substantially higher review level.
Do not approve based on a certification logo alone. Confirm the business associate relationship where applicable, the permitted data elements, retention and deletion behavior, administrator access, breach-notification process, and the clinic’s own risk analysis. HHS describes the HIPAA Security Rule as requiring administrative, physical, and technical safeguards for the confidentiality, integrity, and availability of ePHI.2
K-12 school districts
For a district, the approval packet should identify whether the tool will handle student education records, behavior information, individualized support data, staff records, or merely public curriculum content. The Department of Education administers FERPA and provides assistance to schools and districts in safeguarding student information; FERPA gives parents and eligible students rights concerning education records.5
Make the workflow operational for a school day. A teacher may use an approved assistant to brainstorm a lesson using public material, while a special-education case manager may need privacy and district-approval review before entering student-specific information. The district should also decide whether AI-generated content becomes a record, who reviews it, and how staff report an incorrect or inappropriate output.
Banks, credit unions, and finance teams
For a wire-approval or fraud-review workflow, the key question is not whether AI can identify patterns. It is whether the tool can influence movement of money or expose customer information.
The FTC’s Safeguards Rule guidance calls for a written information-security program, risk assessment, access-control review, application evaluation, testing, and monitoring of service providers6.4 Use those requirements as a vendor-review baseline where the institution falls under FTC jurisdiction, while coordinating with the institution’s own legal and regulatory advisers.
A sensible boundary is: AI may flag a transaction or summarize supporting documentation; a separately authorized employee must approve the wire. Log the recommendation, the human decision, the data used, and any override.
What happens after approval?
The workflow is incomplete without a post-approval control loop. Put each approved tool in an AI inventory with its owner, data classification, integrations, permission scopes, vendor, contract status, test evidence, review date, and shutdown procedure.
Review the tool when any of these events occurs:
- the vendor changes its model, retention terms, subprocessors, or integrations;
- the business process expands to a new data class;
- a new department or service account receives access;
- the tool begins taking actions instead of producing drafts;
- users report fabricated, discriminatory, unsafe, or unexpected outputs;
- the organization experiences an incident or near miss; or
- the scheduled review date arrives.
NIST specifically calls for ongoing monitoring, defined responsibilities, third-party risk controls, and post-deployment plans that include incident response, recovery, change management, override, and decommissioning.1 That is the right mental model for an AI inventory: not a list of software names, but a record of operating responsibility.
Build an approval workflow your team can actually run
A regulated organization does not need a 40-page form for every low-risk productivity experiment. It needs proportional review. A public-facing brainstorming tool may need a lightweight path. An AI agent connected to an EHR, CAD system, student-record platform, or finance application needs a formal path with security and compliance sign-off.
Datapath helps organizations in Modesto, Ceres, Manteca, Merced, the wider Central Valley, Modesto, and California communities including Modesto build that distinction into practical operations. Our AI governance services can support policy design, tool inventory, vendor-risk review, access control, testing, monitoring, and the named-team accountability that follows approval.
The goal is not to block every new tool. It is to make the safe use case easy to approve—and the unsafe data path difficult to hide. If your team is already discovering unapproved AI use through firewall, browser, Microsoft 365, or endpoint logs, start with the inventory and the four gates. Then bring the highest-risk workflows to a documented decision with a real owner.
That is how AI becomes an operational capability instead of an undocumented exception waiting to become an incident.
