AI security for the materials industry: A 2026 brief

Why this guide exists

AI security review in 2026 is not the same exercise it was even a couple of years ago. The questionnaires are longer, and their definitions are more explicit, anchored in a growing set of frameworks. A reviewer working from a 2024 template will miss the questions that matter today, and a vendor answering in 2024 language will read as out of date.

This is a short guide to what has changed and to how responsible vendors are setting a higher bar and what it means for IT teams at materials producers. It is meant to help the CIO and IT groups writing the next version of a vendor questionnaire, and the business leaders who want to understand what AI-vendor review now involves before they begin selection.

What changed in AI security procurement in 2026

Three shifts separate a current questionnaire from one written in 2024.

Generic security controls are now the baseline.

Encryption in transit and at rest, network isolation, RBAC, and SOC 2 alignment are necessary and unremarkable. What sets vendors apart now is a set of AI-specific controls, most of which will be new vocabulary if AI is new to your organization:

Prompt-injection defense keeps the AI from being hijacked by instructions hidden in the content it reads, such as a call transcript or an email, so it stays on the task it was given.
Output grounding and citation links every AI answer back to the exact source it came from, so a person can open the original call, order, or any other record to verify it.
Confidence reporting has the system report how sure it is about each output, so a reviewer knows when to rely on it and when to check it.
Sub-processor transparency at the model layer means the vendor is clear about which outside AI providers process the data and what they are permitted to do with it.
Vector-store isolation keeps one customer’s searchable AI index fully separate from every other customer’s, a point covered in more detail below.
AI-specific incident response is a defined plan for when something goes wrong with the AI itself, not just the general security playbook.

Treating AI as an add-on to a prior questionnaire will miss the areas where risk and differentiation exist.

The questions presuppose governance, not just controls.

ISO/IEC 42001 was published in 2023 as the first certifiable international standard for an AI management system, mirroring the structure of ISO/IEC 27001. Buyers do not yet require certification at scale, but they increasingly want to see that a vendor governs AI deliberately, with a documented program for how AI features are approved, tested before release, reviewed while in use, and handled when something goes wrong. The question has shifted from “what is your cloud security posture?” to “how do you govern AI as a category?”

A shared vocabulary has formed, and it comes from a few frameworks.

A handful of reference documents now set the terms both sides use, and it helps to know what each one is for:

The OWASP LLM Top 10 is a plain list of the ten most common ways AI systems go wrong, from prompt injection to leaking sensitive data. A vendor should be expected to have an answer for each item on it.
NIST’s AI Risk Management Framework gives a simple structure for governing AI, organized as four jobs: govern, map, measure, and manage.
The EU AI Act is law. Its obligations for higher-risk systems take effect on 2 August 2026, carrying penalties of up to €35 million or 7% of global revenue, and its terms are reaching US contracts because European parent companies apply the same policies to their US subsidiaries. Two requirements in particular, human oversight and accuracy, are already appearing in US procurement language.

Knowing these three frameworks is most of what it takes to read a modern questionnaire and understand what it is really asking for.

Tenant isolation: the choice that shapes every other control

Tenant isolation is the foundation of every other security claim in a multi-tenant architecture.

Cloud architecture follows three common patterns. In our industry, a tenant is usually synonymous with an organization, or with an isolated operation inside a larger company.

Pool is a single shared database, with each tenant’s rows separated only by a tenant column that every query has to filter on. It is the cheapest and least secure approach, dependent on every query and every code path staying correct through each update to the software.
Bridge is a shared database with a separate schema per tenant. Operational isolation is better, but the data is still one credential away from cross-tenant contamination.
Silo is a separate database per tenant, with the application connecting to one tenant’s database per request. It is the most expensive to operate and the strongest architecturally. Under a silo, cross-tenant queries are physically impossible, because the engine handling a request has no route to any other tenant’s data.

As the frameworks and the shared understanding of cloud infrastructure have matured, reviewers in 2026 know the distinction, and a vendor’s tenancy choice is a common early procurement question.

The same logic extends to vector embeddings, an additional tier of storage that most AI-using vendors now maintain. Embeddings store text, audio, or image data as vectors, which are numeric representations of semantic meaning. The data is not directly readable by a human user, but it gives AI new ways to process information at scale. Reviewer attention refocused here across 2025 and 2026. Vendors that added retrieval-augmented generation (RAG) often added a separate vector store, such as Pinecone, Weaviate, or Chroma, outside the primary database, and that separate store can carry weaker tenancy properties than the primary one. The failure mode reviewers now probe for is the vector tier leaking across tenants while the primary database stays correctly isolated. The stronger architectural answer is to co-locate the vector index inside the same per-tenant database, so the embeddings inherit the silo isolation. That choice closes the OWASP LLM08 (Vector and Embedding Weaknesses) concern at the architectural level rather than the operational one.

Keeping the vector index in the same per-tenant database also makes several routine operations cleaner: backing up, restoring, or deleting one tenant’s data on its own; letting each tenant hold its own encryption key; and cleanly separating a tenant’s data when a contract ends. A vendor does not choose silo for these conveniences; it chooses silo for the isolation, and the conveniences come with it. The cost is real, since operations teams build tooling that pool-architecture vendors never need, but it is a bounded, one-time cost.

Defense-in-depth and the PII/PCI/PHI distinction

A second consideration takes on new meaning in systems built around AI, which is how to protect against the oversharing of personal, sensitive, and compliance-regulated information. AI systems increasingly process raw text and communications data. Earlier systems constrained their inputs more tightly, and even then, entering a credit-card number into a notes field was a common workaround across the industry. Handling this information properly matters both for security posture and for regulatory compliance, and it is a central question for any reviewer or vendor processing unstructured data through AI.

The three categories are distinct:

PII (personally identifiable information) is the ordinary information about who is doing what: a person’s name, their role in the process, and how to reach them. In an industrial operation, AI will generally need to work with it, because making sense of an interaction means knowing which person, in which role, was involved. This is operational identity, not the personal information that should never be shared, which is what PCI and PHI cover. Even so, PII is more sensitive than ordinary operational data, and depending on the region it carries real compliance obligations such as GDPR. The right posture is to protect it closely, limit how widely it is processed and exposed, and handle it according to the rules that apply where the operation runs, which in many regions also include deleting a person’s information on request.

PCI (payment-card data), meaning primary account numbers, CVVs, and card expiry, has limited operational value in a non-payment platform and is high-risk under PCI DSS v4.0. The right posture is strip at every feasible layer.

PHI (protected health information), meaning medical conditions, diagnoses, injury accounts, and drug references, surfaces incidentally in healthcare-adjacent verticals and in industrial operations with safety-critical workflows. The right posture is the same as for PCI: strip at every feasible layer.

A reviewer’s first redaction question in 2026 should test whether the vendor distinguishes these three categories at all. The answer reveals whether the vendor has thought about which data the product needs and which is only incidentally present.

Most industries encounter one or two of these categories, and some encounter all three. Materials producers are in that last group. Dispatcher and order-taker conversations carry PCI when cardholder data is read aloud during cash-on-delivery (COD) transactions, and the same conversations carry PHI when an injury is reported, or when medical detail is shared incidentally in explaining why a driver is out or why an on-site contact has changed. Carrying all three categories, at the volume a materials producer generates, is uncommon. Technology built for the industry, prepared to handle these data in a safety-critical, cash-handling domain, is a better fit than horizontal software that may not account for the nuances of a producer’s operation.

Within a vendor’s system, the answer is layered defense, where no single layer is assumed perfect and each catches what the one before it missed. The layers can include:

Pattern matching for structured data. Fixed-shape items such as card numbers can be caught by exact matching, with a checksum to confirm a number really is a card number before anything is removed.
Redaction during transcription. A speech-to-text service can strip sensitive content as it converts a call to text, before that text is ever stored.
Instructions to the model itself. A model can be told to replace sensitive details with placeholders wherever they appear.
A dedicated model for written text. A purpose-built model can scan channels like email and messages for health and personal information that has no fixed shape.

Not every vendor processes all three categories of data, and which of these layers matter most depends on what the software actually does. But a vendor that is clear about the categories it handles, and applies layered defense where it counts, is well positioned to protect the sensitive information an operation may generate.

The third-party LLM question

The most-asked AI security question of 2026 is some version of: are the LLM providers training their models on my data?

Answering it well means keeping two parties straight. The LLM provider is the company that builds the model, such as OpenAI or Anthropic. The cloud provider is the company whose infrastructure the model runs on, such as AWS, Google, or Microsoft. Sometimes they are the same party and sometimes they are not, and that difference is the heart of the question. A credible 2026 answer covers four things.

Where does the model run? Directly against an LLM provider’s own API, on a cloud provider’s model-hosting service such as AWS Bedrock, Google Vertex AI, or Azure OpenAI (sometimes called a model-deployment plane), or in a private deployment the vendor controls.
Who can see the prompts and the model’s answers? On a direct API, the LLM provider generally keeps logs for abuse detection and may retain the content. On a cloud provider’s model-hosting service, the model runs inside an account the LLM provider does not control, so the LLM provider has no way to reach the data being sent to the model.
Is the model trained on customer content? This turns on two separate policies, and both matter: the LLM provider’s, and the cloud provider’s. A credible answer confirms that neither one uses customer content to train or improve its models.
Can the customer exclude specific providers? A buyer whose risk posture rules out a particular LLM provider expects to enforce that in the vendor’s system, at the point where requests are routed, rather than as a setting that could be overridden.

The category shift here is from calling an LLM provider’s API directly to running the model on a cloud provider’s model-hosting service. AWS Bedrock is the clearest example: LLM providers, including Anthropic, Meta, Mistral, Amazon, and Cohere, make their models available inside AWS-controlled accounts where they themselves have no way to reach the data, and AWS does not use customer content to train any of those models. The question of what the provider does with the data then gets a structural answer, that it has no path to it, rather than a contractual one. The same pattern is available on Google Vertex AI and on Azure’s hosted model offerings. A vendor that has made this shift, and can explain what it means for procurement review, is answering in the vocabulary reviewers now use.

Confidence, citations, and human oversight

EU AI Act Article 14 requires that humans be able not merely to observe AI outputs but to correct them. The procurement question is some version of: show us the human-oversight surface.

A credible answer has three components, each visible in the product rather than asserted in a policy document.

The first is confidence scoring on every AI output, and not as a single number. Two different signals matter:

How sure the model is of a specific value. For structured items such as dates, amounts, and identifiers, the model can report its own certainty that it read the value correctly.
How faithful an answer is to its source. For free-text outputs such as summaries and generated notes, a separate signal can check whether the text actually matches the record it was drawn from, rather than drifting from it.

Telling these two apart is now part of the procurement vocabulary.

The second is source provenance with citations. In a credible answer, each generated output links back to the source it was drawn from, such as a call segment, order record, or transcript line. Explainability in 2026 means traceability from generated content back to source material, not a confidence number standing alone.

The third is a built-in correction surface, meaning a feedback control on every AI-generated output, with that feedback feeding back into how the vendor improves its prompts, tests, and models. The point is not the interface interaction itself, but that a human correction can be submitted and is connected to how the system gets better.

Together, the three satisfy Article 14 beyond what a policy statement can. Auditors increasingly ask for screenshots, schema definitions, or DPIA-style evidence of this feedback loop. A vendor that has built the loop can produce that evidence. A vendor that has only documented it in a policy cannot.

The training data question

Beyond the question of LLM-model training, a second 2026 question asks whether the vendor itself trains models on customer data. Most reviewers ask it as a binary. The better answer is not binary, because a flat “we do not train on your data” neither distinguishes between training postures with materially different risk profiles nor accounts for the data required to deliver valuable foundational capabilities to the industry.

A more durable framing is tiered.

Tier 1: inference only. Customer data is used only for inference, with no training, no fine-tuning, and no model improvement on customer content. When the model runs on a cloud provider’s model-hosting service, the LLM providers have no access path, and the cloud provider does not train on customer content for hosted models. This is the default and operative state for most vendors and most customers today.

Tier 2: aggregated, statistical-only training across the platform. Some features deliver value only when trained on data spanning the platform, such as industry benchmarking, cross-network anomaly detection, and market-level signal extraction. The training data is fully flattened to numeric, statistical-only aggregates, with no specific orders, calls, customer or producer identifiers, or transcribed content. The permitted uses are enumerated explicitly in the customer contract.

Tier 3: customer-isolated retrained model. A dedicated retrained instance of a pre-built model, trained only on a single customer’s data and accessible only to that customer. It is an enterprise option, with costs passed through.

The tiers are anchored in contract. A “no training” DPA corresponds to Tier 1 only, and a vendor cannot promise Tier 2 features into a Tier 1 contract.

A note on language: “anonymized” has become a contested claim under GDPR Article 4 and subsequent EDPB guidance, and a buyer’s privacy counsel will challenge it. “Fully flattened to numeric, statistical-only aggregates” is verifiable in a way that “anonymized” is not, and vendors that use the more specific language are signaling that they expect the question.

AI governance as a category

The 2026 procurement question that did not exist before is: how do you govern AI as a category, separately from general software change management?

ISO/IEC 42001 and NIST AI RMF are complementary, and each does a different job:

ISO/IEC 42001 sets the structure of an AI management system, in the same way ISO/IEC 27001 sets the structure for information security.
NIST’s AI RMF supplies the working vocabulary for running that system, organized around four jobs: govern, map, measure, and manage.

Buyers do not yet require ISO/IEC 42001 certification at scale, but they do expect evidence of alignment: a documented program an auditor could trace back to the standard.

A responsible AI vendor in 2026 can show a few concrete things:

The instructions given to the AI are version-controlled, like software. The prompts and settings behind each feature are tracked, and any change to a model or a prompt goes through review and approval before it reaches production.
Every AI feature has an automated test suite. Before a new model is put into use, it is run against saved examples to confirm it returns the right format, still removes sensitive data, and reports its confidence correctly.
Real outputs are spot-checked on a schedule. A sample of the AI’s production output is reviewed for accuracy at a set cadence, and what is found feeds back into improving the prompts.
User corrections are captured as evidence. The feedback control described earlier gives an auditor ongoing proof that the program actually runs in production, which is worth more than a quarterly meeting minute.
There is a plan for AI-specific incidents. Standard incident response is extended to cover AI-specific events, such as an output that caused harm, a suspected prompt-injection attempt, or an incident reported by an LLM or transcription provider.

Reviewers should ask to see evidence of each of these, not policy descriptions. A program that exists only on paper still has to be shown to operate.

Customer controls and sovereignty

The 2026 expectation is that customer administrators have direct, in-product control over how AI features process their data, not just an assurance that the vendor follows its own policies.

The control set buyers now expect covers a few things:

Turn AI features on or off, for the whole account and for individual features, so an administrator decides where AI is used.
Exclude specific AI providers from processing the account’s data, enforced by the vendor’s system rather than left to a preference that could be overridden.
Set how long each type of data is kept, within the ranges the contract allows.
Export the account’s data on the customer’s own initiative, in a defined format and within a stated time.
Delete the account’s data on the customer’s own initiative, within a stated time.
Review an audit log of activity that cannot be altered, through an administrator-facing screen.

Few vendors will offer all of these as ready-made surfaces today. The reviewer’s job is to assess the gap, and to judge whether a missing item is designed-in, meaning the architecture is in place and the surface is still being built, or undesigned, meaning the architecture would have to be retrofitted.

For the most demanding buyers, one capability matters more than any single in-product setting: letting the customer manage access to the vendor’s product through the identity system it already runs, such as Okta, Microsoft Entra ID, or Google Workspace. With that connection in place, the customer’s own system decides who can sign in, what each person is allowed to do, and how multi-factor authentication is enforced, and it adds or removes people automatically as they join or leave. The standards that make this work are SAML 2.0 for single sign-on and SCIM 2.0 for account provisioning. It is not a free switch to turn on: it takes real engineering and upkeep on the vendor side and shifts some access-related support to the customer, so most vendors offer it as an enterprise-tier option priced accordingly.

Technology built for the industry, and where things are going

A vendor serving a single industry can describe its data inventory specifically, rather than against a lowest-common-denominator hypothetical. That makes the threat model bounded and defined, the redaction surface calibrated to the sensitive data that actually appears in the industry, and the AI-feature inventory a finite list rather than the open-ended capability a direct LLM service or horizontal software presents. Industry specialization is moving from a sales-motion attribute to a security-posture attribute: the more specific the data inventory, the more credible the controls described against it.

The direction of travel through the rest of 2026 and into 2027 is visible in a few places.

ISO/IEC 42001 becomes the durable certification surface and NIST AI RMF remains the operational grammar, the two coexisting the way ISO/IEC 27001 and SOC 2 coexist today.
EU AI Act enforcement accelerates the procurement effect already visible, as EU-headquartered parents push group-policy terms into the contracts of US-incorporated subsidiaries.
The shift from direct-API LLM integrations to model-deployment-plane integrations continues. By 2027, a vendor still running direct-API integrations for sensitive workloads will face harder procurement questions than one that has cut over.
Auditors and reviewers keep pushing from policy-document review toward in-product evidence, such as confidence-score schemas, feedback-control screenshots, audit-log samples, and change-management ticket histories.

A vendor whose evidence comes from running the program answers these questions more convincingly than one that can point only to written policy.

Closing

This is a guide, not an architecture disclosure. It describes the patterns, the standards, and the procurement environment that AI security review in industry technology has reached by mid-2026. Where the patterns are applied in a specific architecture, that discussion lives in the companion document. The guide is written from the materials-industry vantage, but the patterns are general and carry across verticals. As AI adoption spreads within each industry, the security and governance vocabulary has matured, and the playbook for responsible adoption is now visible.