Using AWS AI Without Displacing Your Manufacturing Systems of Record

The problem: assistance that drifts into authority

AWS describes a Guidance for aerospace manufacturing in which ERP, MRP, and HR systems synchronize to cloud storage nightly and streaming events update near real-time production status. That pattern shows how operational data can be copied into an analytics and AI environment. A copy is not the system of record. Once records are copied, indexed, and summarized, the copy can lag, lose permissions, or be quoted without its source.

Three failure patterns follow from that. An assistant answers from a stale or unapproved document revision. A user acts on a recommendation as if it were an approved transaction. Or sensitive quality or customer information becomes visible to people who could not see it in the originating system. Each one is an ownership gap rather than a model problem.

Why this is hard: causes and constraints

The constraints are practical. Data ownership differs by system: orders and inventory in Odoo, execution status in the MES, nonconformances and corrective actions in the QMS, controlled documents elsewhere. Data quality varies, and integration capacity is limited.

AWS documents the mechanics that create these dependencies. When you create a Bedrock knowledge base, you set up a service role with permissions to the knowledge base and choose an embeddings model and storage for the embeddings. Each choice carries a consequence. Higher vector dimensions improve accuracy but increase cost and latency, and a knowledge base must be synced for the first time and whenever content needs to stay current. Freshness is therefore an operating task someone must own, not a property that arrives automatically.

Government guidance points the same direction for the control side. CISA and international partners published principles for AI in operational technology, and they call for educating personnel, assessing AI use, establishing AI governance, and embedding safety and security.

Approaches to compare

There is no single correct path. Evaluate these options against your own systems and risk tolerance.

1. Extend existing systems. This keeps authority where it already sits, but it may not span several systems or unstructured documents.
2. Targeted integration. Move specific records or events to a shared store for one use case. This limits scope, but each integration needs an owner and a refresh rule.
3. Reporting or portal patterns. Present governed information to people without generating new text. This is the most conservative option, though it provides less assistance.
4. No platform change. Sometimes the right answer is to fix the underlying process or data first.
5. A governed AI implementation. Retrieval and assistance over an approved corpus, with logging and review. AWS's supply chain lens describes Amazon Comprehend analyzing supplier communications and feedback and Bedrock generating supplier communications and analyzing responses. Those descriptions show the kinds of capabilities available. Whether any of them fits your operation is a question for your own assessment.

Choose the smallest option that solves the stated problem. A governed AI build is warranted only when the use case needs capabilities the simpler options cannot provide.

Tradeoffs to weigh

Every approach trades effort against control. A broader corpus gives more helpful answers and also widens the access and quality risk. Richer logging helps investigation but creates stored data of its own. AWS notes that model invocation logging is disabled by default, and that logs can capture request data, response data, and metadata, delivered to Amazon S3 or CloudWatch Logs. Likewise, AWS states that image or document data passed through the Converse API is logged in Amazon S3 when delivery and image logging are enabled, so decide deliberately what you want captured, and decide who may read the logs and how long they are kept.

Other limits are yours to measure rather than assume: cost and latency at your volume, the quality of your documents and master data, vendor dependency, and the support burden of keeping the corpus current. Adoption matters as well. If people cannot see where an answer came from, they will either distrust it or over-trust it.

Next steps: an implementation sequence

1. Define one use case, the approved corpus, the access boundary, the source of authority for each content type, the retention rule, and a named accountable owner. Do this before connecting any operational information.
2. Separate the modes of AI output: retrieval, drafting, recommendation, transaction preparation, and autonomous action. Decide which modes are in scope and who approves anything that would change a record.
3. Build permissions into retrieval so a user sees only what they could see in the source system, and require citations back to the source record or document revision.
4. Turn on logging deliberately, choose destinations in the same account and Region, and set retention and access for the logs themselves.
5. Define evaluation with real questions and known answers, a human review step, an incident path for wrong or exposed answers, and change control for corpus, model, and prompt changes.
6. Pilot with a small group, measure answer quality and refresh lag, then decide whether to widen scope.

Applying this as a business leader

Bring five questions to your team before approving any AI-over-operations project. Which system is authoritative for each kind of information the assistant will use? Who owns the approved corpus and its refresh? What can the assistant do besides answer, and who approves anything that changes a record? How will you know when an answer was wrong, and who responds? What happens to the logs and the data they contain?

If the team cannot answer these plainly, the project is not ready to connect operational data.