Before adopting AI, prove that your organization can control what the system can see, what it can do, and what happens when it is wrong. Start with one low-risk workflow, document its data and permissions, test monitoring and rollback, and approve expansion only when the evidence—not the demo—supports it.
At 7:42 on a Tuesday morning, a controller at a 120-employee company in Modesto is testing an AI assistant connected to Microsoft 365 and the accounting platform. The assistant can summarize vendor emails, compare invoices, and prepare an ACH approval queue. The demo looks productive—until it finds a forwarded spreadsheet containing banking details, pulls in an email thread that was never meant for finance, and drafts a payment using a vendor account that changed last week.
Nothing has been sent yet. But the decision has arrived: can this company safely give an AI system access to a real operating workflow?
That question is more useful than asking whether the vendor is “secure.” AI readiness is not a product feature. It is the ability to enforce boundaries, observe activity, review decisions, and stop the system without disrupting the business.
What does cybersecurity readiness for AI actually mean?
For a mid-market organization, readiness means you can answer five questions before connecting AI to production data:
- What data can the system access? Include shared drives, mailboxes, EHR or ERP records, cloud storage, support tickets, and backups—not just the folder named in the project plan.
- What actions can it take? Reading, summarizing, creating a draft, changing a record, sending an email, approving a transaction, or calling another application are very different permissions.
- Who is accountable for the outcome? Name the business owner, technical owner, security reviewer, and person authorized to disable the tool.
- How will you know when it fails? Define logs, alerts, review queues, error thresholds, and escalation paths before launch.
- How do you stop it? A useful AI deployment needs a tested kill switch, credential revocation process, rollback plan, and human fallback for the underlying workflow.
NIST’s AI Risk Management Framework organizes AI risk work into govern, map, measure, and manage functions.1 That is a practical sequence for an AI readiness review: establish ownership, understand the system and its environment, test the controls, then decide how to treat the remaining risk.
The key distinction is between a safe pilot and an uncontrolled integration. A read-only assistant that summarizes an internal policy library is not the same risk as an agent that can modify an HR record or send a wire instruction.
Which AI use case should you approve first?
Do not begin with the most exciting use case. Begin with the use case that has a contained failure mode.
A useful first-pass scoring model is to rate each candidate from 1 to 5 in four categories:
| Readiness factor | 1-point condition | 5-point condition | What to verify |
|---|---|---|---|
| Data sensitivity | Public or already-approved information | Patient, student, CJIS, financial, payroll, or confidential client data | Classification, retention, vendor handling, and whether prompts or outputs are used for training |
| Action authority | Read-only response | Sends, changes, approves, deletes, or executes | API scopes, delegated permissions, approval gates, and separation of duties |
| Failure impact | Inconvenient rework | Safety, financial, operational, or legal consequence | Manual fallback, recovery time, and who reviews output |
| Observability | Basic vendor dashboard | Exportable event logs tied to users and actions | Identity, timestamps, prompts or requests, tool calls, outputs, and administrator activity |
| Recovery | Disable a user manually | Tested system-wide shutdown and rollback | Credential revocation, connector removal, restore point, and documented owner |
If a use case scores 15 or more, it is not automatically approved. It is a signal that the review needs stronger evidence. For a first pilot, we generally prefer a read-only workflow with no sensitive data, no external sending, and a human review of every output.
CISA’s guidance on agentic AI recommends beginning with low-risk, non-sensitive use cases and avoiding broad or unrestricted access to sensitive data or critical systems.2 That is especially important when an AI system can call tools, follow instructions from incoming content, or make decisions across multiple applications.
A practical starting sequence
- Start with a bounded knowledge task. Use an approved document set, such as internal procedures or publicly available product documentation.
- Make the first version read-only. Do not allow the system to send messages, modify records, create accounts, or approve transactions.
- Use synthetic or sanitized data. Test realistic edge cases without exposing production secrets.
- Require named human approval. The reviewer should see the source material and the proposed action, not just an AI-generated conclusion.
- Expand one permission at a time. Treat every new connector or action as a new risk decision.
Can your identity and access controls contain the AI?
Most AI readiness problems are not caused by the model alone. They occur because the model inherits access that was already too broad.
Before a pilot, ask your IT or security team to produce an access map showing:
- The user, service account, or workload identity used by the AI tool.
- Every application, mailbox, site, shared drive, database, and API it can reach.
- Whether access is read-only, write-enabled, or capable of executing a transaction.
- The approval required before a high-impact action occurs.
- How credentials are stored, rotated, and revoked.
- Whether a departing employee’s access, group membership, or tokens can leave the AI connected to data.
An AI assistant should not become a shortcut around least privilege. If a finance employee can access ten years of shared-drive archives, connecting an AI assistant to that employee’s account may expose all ten years at machine speed.
We also look for identity controls that produce attributable activity: multifactor authentication, conditional access, separate administrator accounts, privileged-access review, and logs that identify the person or workload behind an action. “The AI did it” is not an incident record or an accountability model.
For Microsoft 365 environments, this review should include the tenant’s sharing settings, application consent, mailbox delegation, audit configuration, retention rules, and the permissions granted to the AI vendor. For other platforms, the same principle applies: inventory the connector, not just the marketing name of the product.
What should you test before connecting production data?
A security questionnaire from the vendor is useful, but it is not a readiness assessment. You need to test your own environment and the exact workflow you plan to use.
Test data boundaries
Create test prompts and documents that represent the mistakes a real employee might make:
- A confidential attachment forwarded to the wrong mailbox.
- A document containing an old password or API key.
- Two conflicting versions of a policy.
- A malicious instruction hidden inside a document.
- A customer request that asks the system to ignore internal approval rules.
Verify whether the AI can retrieve, quote, summarize, or transmit information outside its intended boundary. Test both direct questions and indirect instructions embedded in files or messages.
NIST’s AI RMF says organizations should map risks across all components of the AI system, including third-party software and data, and define human oversight processes.1 That means the review must include the model provider, plugins, connectors, retrieval store, logging service, administrator console, and downstream applications.
Test output quality and decision rights
Give the system known-bad, incomplete, and ambiguous inputs. Measure whether it:
- States uncertainty instead of inventing an answer.
- Cites or links to the source material used.
- Routes sensitive or ambiguous cases to a human.
- Preserves required records.
- Refuses actions outside its assigned scope.
- Produces a useful audit trail.
Set a number before testing. For example, a first pilot might require 100% human review, zero unauthorized writes, and zero access to data outside the approved test set. The point is not that these thresholds fit every organization; the point is that “it seemed accurate” is not a control.
NIST describes measurement as testing AI systems before deployment and regularly while they operate, with documented methods, metrics, uncertainty, and reporting.1 Build the test record while the pilot is small, when correcting the design is cheaper.
How do regulated teams adapt the readiness review?
The same readiness method applies across Datapath’s markets, but the protected workflow changes.
Healthcare and clinics
If the AI can touch electronic protected health information, the review should begin with a risk analysis and an inventory of where that information enters, moves, is processed, and is stored. HHS describes risk analysis as foundational to identifying and implementing safeguards under the HIPAA Security Rule3.4
Do not limit the review to the AI application. Include the EHR connector, transcription service, browser extension, administrator account, backup, export file, and vendor support path. Confirm access control, authentication, audit logging, transmission security, and a business associate arrangement where applicable. HHS specifically identifies controls for access, audit activity, authentication, and transmission security in its Security Rule summary.
A safer first workflow might summarize de-identified appointment instructions for a nurse manager—not draft clinical decisions or send patient communications without review.
K-12 school districts
Map student records, staff data, special-education information, transportation systems, learning platforms, and shared drives. A chatbot that answers questions from an approved public handbook has a different risk profile from one that can search student records.
The operating test should include the bell schedule, substitute-teacher workflow, parent communications, and the district’s process for correcting an inaccurate answer. Define what the AI may retain and who can review its logs.
Local government and public safety
For a county IT team or dispatch environment, separate general administrative assistance from systems handling criminal justice information. The FBI’s CJIS Security Policy governs the creation, viewing, modification, transmission, dissemination, storage, and destruction of criminal justice information.5
An AI tool that summarizes a public meeting agenda should not inherit access to dispatch records, evidence repositories, or law-enforcement systems. For CJIS-regulated workflows, document the data path, access boundary, logging, human review, retention, and disablement procedure before testing with live information.
Finance, banks, and credit unions
Treat wire approval, account changes, customer-service records, and fraud operations as high-impact workflows. Start with a read-only reconciliation or policy-search use case. Keep payment initiation, beneficiary changes, and exception approval behind existing dual-control procedures.
Mid-market businesses
For a company with roughly 100 or more employees, AI adoption often crosses departments faster than governance can keep up. A security review should cover shadow AI subscriptions, browser extensions, personal accounts, sales tools, recruiting platforms, and the official enterprise deployment.
Our managed cybersecurity services and vendor risk management teams can help turn that scattered inventory into a decision record with owners, permissions, and remediation priorities.
What does a real AI go/no-go decision look like?
At the end of the review, produce a one-page decision record. It should state:
- The approved use case and business owner.
- The exact data sources and prohibited data types.
- The AI system, model provider, connectors, and service accounts.
- Allowed actions and actions that require human approval.
- Test cases, results, failure thresholds, and unresolved issues.
- Logging, alerting, retention, and review frequency.
- Incident response, rollback, and shutdown steps.
- The date and condition for reassessment.
Approve only when the unresolved risks are understood and accepted by the right owner. Pause when the vendor cannot explain data handling, when permissions cannot be narrowed, when logs cannot be reviewed, or when no one owns the decision to stop the system.
NIST’s framework makes the same point operationally: after mapping context and impacts, organizations should have enough knowledge to make an initial go/no-go decision; if they proceed, they continue measuring and managing risk as the system changes.1
How can Datapath help you prepare?
We do not treat AI adoption as a software installation. We start with the workflow: what your team is trying to improve, what information it handles, what could go wrong, and what must remain under human control.
Datapath can help your Modesto, Fresno/Central Valley, Modesto, or California-based organization inventory AI use, review identity and endpoint controls, assess vendor and connector risk, define a controlled pilot, and prepare the monitoring and response plan around it. If your security team needs additional leadership, our vCISO services can provide a named security partner; if the project needs business alignment, our vCIO services can connect the technology decision to operating priorities.
For teams ready to establish an AI-specific policy and approval process, our AI governance solution is a practical place to begin. The goal is not to block useful automation. It is to make sure the first AI deployment is observable, reversible, and accountable before it reaches the workflow your organization cannot afford to disrupt.
