← Blog

Essay

Why your first AI use case shouldn't touch sensitive data

May 7, 2026

The conversation in most regulated-industry boardrooms in 2026 is the same conversation: "How do we use AI without exposing our data?"

It is the wrong first conversation.

The right first conversation is: "Which workflows in our company don't involve sensitive data at all?" Once you ask that question, the AI build becomes simple, and the data-exposure question stops being a blocker for the first 90 days of work.

This is the playbook I take into pharma, financial services, and defense-adjacent companies that are two years into AI strategy meetings and zero years into a working tool.

Why "secure the data" is the wrong place to start

When a regulated company sits down to evaluate AI, the default frame is risk management. Patient data. Trade secrets. Material non-public information. Personnel files. Each of those categories has a regulatory regime and an internal owner who can block any project that touches it.

The default response from AI vendors is a security-and-compliance pitch. Zero data retention. HIPAA business associate agreements. Customer-managed keys. VPC isolation. Cloud-tenanted inference via Bedrock or Vertex or Foundry where data never crosses to the model provider. All of those mechanisms exist. All of them work in practice.

But the executive evaluating the pitch doesn't hear "this is solved." They hear "a vendor is asking me to trust them with the most sensitive thing my company owns." Even when the technical answer is correct, the political answer is "not yet." The pilot stalls in legal review for six months. Then it dies, because the urgency that started it has moved on to the next quarter.

The companies I see actually shipping AI in regulated industries are not winning the data-security argument first. They are skipping it on the first build.

The procurement-first thesis

Procurement is the right starting surface for regulated-industry AI in 2026 because the data is operational metadata, not regulated content.

When a procurement analyst at Lilly, Cummins, or Corteva reviews a vendor contract, the document contains payment terms, SLA commitments, liability caps, renewal dates, data-handling clauses, and termination rights. None of that is patient data. None of that is trade secrets. None of that is MNPI. It is contract language the company has been reviewing the same way for thirty years. AI on that surface introduces zero new data-handling risk.

The same property holds across most of the procurement function:

• Vendor contract clause extraction. The contract is between the company and a vendor. The vendor knows everything in it.
• RFP response evaluation. The responses came from outside vendors who voluntarily submitted them.
• Spend categorization. The underlying invoices already sit in an ERP under standard access controls. Categorization is a metadata operation.
• Procurement intake routing. Internal employees submitting requests through a form. The data is process metadata, not content.
• SAP Ariba workflow automation. Operational events.
• Vendor master data cleansing. Names, addresses, tax IDs, payment terms. Already shared with the vendor.

Each of these workflows has the three properties that make a first AI pilot succeed: a person currently reads documents and produces a written output, the volume is high enough to measure ROI in 30 days, and the data being processed is not the data that triggers a six-month legal review.

That last property is the unlock. A procurement-first pilot is not a security argument. It is an operational ROI argument with the security argument already cleared, because there is nothing to clear.

What this changes about the buying conversation

A regulated-industry executive who has been told "AI requires extensive data review" is going to be skeptical of any pitch that promises to compress the review. They have been promised that before.

A pitch that says "we are going to skip the data review entirely on the first project, ship measurable ROI in 30 days on a workflow that doesn't touch sensitive data, and use that credibility to earn the right to harder workflows in 90 days" is a different kind of pitch. It does not require trust in the vendor's security architecture on day one. It requires trust in the consultant's ability to scope. That is a much smaller leap.

The pitch also gives the executive an answer to the question their security team is going to ask. "Which data is this AI tool processing?" "Vendor master records and contract metadata. No PII, no PHI, no MNPI, no trade secrets." That is a sixty-second conversation with the CISO, not a sixty-day risk review.

The 90-day expansion path

Procurement is the wedge, not the destination. The pattern that works in regulated industries is straightforward.

Days 1 to 30: ship a procurement workflow. Vendor contract clause extraction is the most common first build. The deliverable is a tool that takes a PDF contract in and produces a structured summary out, with key clauses flagged. The data is non-sensitive. The output is reviewable side-by-side with what the analyst would have produced manually.

Days 31 to 60: measure and expand inside procurement. Add a second workflow on the same data class. RFP scoring, vendor renewal alerting, spend categorization. The security review has already happened. The model and infrastructure are already approved. The expansion is operational, not procurement-of-AI.

Days 61 to 90: graduate to adjacent low-sensitivity workflows. Internal IT helpdesk on already-public documentation. Sales operations on already-shared collateral. HR on policy documents, not personnel files. Each of these is a step toward higher-sensitivity workflows without making the next step the hardest one.

Months 4 to 6: sensitive data, with credibility. By month four the company has shipped three to five working AI tools on operational metadata. The internal narrative has shifted from "AI is risky" to "we already ship AI." The next build can take on a workflow that touches regulated data, with a security review that benefits from four months of operational track record.

What this means if you are evaluating a vendor

If you are an AI buyer in a regulated industry and the vendor in front of you is leading with their security architecture, ask them one question. "What workflow are you proposing for the first 30 days, and what data does it process?" If the answer involves any data that needs more than a sixty-second conversation with your CISO, the vendor has misread your stage. Either they are pitching the wrong workflow, or they are pitching the right workflow with the wrong frame.

The vendor you want is the one whose first proposal is a workflow you could sign off on without legal involvement, because the data is operational metadata and the value is measurable ROI on tedious work. That vendor understands that the first build's job is to earn credibility, not to prove the security architecture.

Where I sit

I do this work for mid-market and regulated companies based out of Indianapolis. What I am paid for is choosing the workflow, scoping the 30-day pilot, and shipping the script that produces the output. The output goes to the workflow owner first. They review it side-by-side with their own work. The pilot ships when the output is good enough that the workflow owner would use it without supervision. Then we expand.

If you are six months into AI strategy meetings and zero months into a tool that does anything, the first hour of work is choosing the workflow. We can do that together.