Engineers and business experts should work together to define how AI uses company data to support specific decisions. Automating data ingestion and routine, repeatable updates give engineers more time to test AI systems against real work.
Key Takeaways
- A working chatbot does not show whether an LLM will retrieve the right contract or correctly classify an unfamiliar alert.
- Business experts are the people who can discern whether AI is delivering acceptable answers backed by the right evidence or making costly mistakes.
- Engineers and business experts should work together to define what correct answers and behavior from AI look like and which errors make AI answers unacceptable.
- Standard AI components like a foundation model and supporting libraries reduce the amount of software engineers must build but can't determine which business rules the AI system should apply.
- Engineers can spend more time on AI evaluation and integration if you automate repeatable data preparation and maintenance work.
- Engineers should evaluate models using data the models did not train on (including environments that differ from the development data) and keep retrieval updates separate from changes to model weights.
Why does AI production work extend beyond a model demo?
AI production work extends beyond a model demo because a working chatbot does not show whether a large language model, or LLM, will retrieve the right contract or correctly classify an unfamiliar alert. Engineers need tests that expose those failures before deployment; building those tests requires knowledge of the work the system will support.
When my team adapted a model for security alert triage, we encountered risks that a demonstration could miss:
- The training and production prompts needed the same chat template, including role markers and special tokens. Different formatting can change how the model interprets the input.
- Near-duplicate alerts could cross the boundary between training and test data. That overlap can make evaluation scores look better than performance on new incidents.
- A larger model matched our validation score but performed worse on a network it had never seen. The familiar validation data did not reveal that weakness.
That’s why I recommend this approach for testing your models for accuracy:
- Split your training and test data by incident, then evaluate the model on a network it has never seen. Be sure to measure the model’s “recall” (the proportion of serious alerts it catches) since its overall accuracy can be high even when it misses serious threats.
- Enlist your business experts to help define acceptable rates for missed threats and unnecessary escalations.
- Build your test set around the decisions the system must make. For each case, record the expected outcome and the source evidence that supports that outcome. Keep a final test set separate from the examples you use to tune the model or choose retrieval settings.
Why should business experts help specify AI system behavior?
Business experts should help specify AI system behavior because they’re the people who can discern whether AI is delivering acceptable answers backed by the right evidence or making costly mistakes.
This is the collaborative process I recommend:
- Business experts give engineers examples of acceptable answers and exceptions (e.g., a contract exception allows a shipment to arrive after the standard deadline) as well as costly mistakes.
- Engineers turn those examples into tests to check if answers are correct and if answers apply the correct source evidence (e.g., check whether the AI system connects an exception to the right shipment record, make sure the AI system doesn’t include an expired contract in an answer about a specific supplier, etc.).
- Business experts identify missing data.
- Business experts and engineers jointly commit to an AI design.
How does collaboration between engineers and business experts change engineering specifications for AI?
Collaboration between engineers and business experts changes engineering specifications for AI because engineers use input from business experts to define what correct AI behavior looks like.
This delivery support application illustrates the difference:
| Design question | Generic starting point | Specification with business input |
|---|---|---|
| What should it do? | Answer questions about documents. | Explain delivery exceptions using contracts and shipment records. |
| Which data does it need? | Documents about the shipment or delivery issue | Shipment records linked to applicable contract terms and exceptions. |
| What should tests check for? | Relevance and readability | Whether answers cite the right records and whether answers identify exceptions. |
| When/how should it escalate? | Use a general fallback when the system cannot answer. | Escalate when evidence is missing or conflicting. |
Why do standard AI components need business context?
Standard AI components need business context because a foundation model and supporting libraries do not determine which business rules the AI system should apply; they only reduce the amount of software a team must build. Business experts identify relationships for AI. Engineers encode and test those relationships.
Common components address different technical needs:
- Low-rank adaptation, or LoRA, trains small matrices that modify selected model layers while the original weights remain frozen. It changes model behavior without updating every base weight.
- Retrieval-augmented generation, or RAG, retrieves relevant records and includes them in the context supplied to the model. The retrieved content can change without retraining the model.
- An agent loop lets a model request tool calls and use their results in later steps. Application code must define which tools the model can call and when execution stops.
This is why two distributors using the same foundation model and retrieval library will produce significantly different results. With one, a similarity search for "late delivery" can return related passages without establishing which exception applies; with the other, AI can correctly explain a missed delivery because it understands the applicable contract terms (source data) and actual shipment events (relationships).
I used the concepts behind the three components as the foundation for 4Minds, so our platform can build and adapt select models. It’s why AI systems built with 4Minds can deliver accurate, business-specific results.
How can I reduce repeated work in data preparation?
You can reduce repeated work in data preparation by deciding how to split documents into retrievable sections then testing whether retrieval returns the evidence needed for representative questions. A small section can omit qualifying language while a large section can consume the model's input budget with irrelevant text.
An extraction pipeline identifies entities and relationships in source documents. A graph database stores the results. When documents change, the team must update the affected records and retrieval index. A change to source facts does not by itself require a change to model weights.
This work affects answer quality. When you automate repeatable processing after engineers define and test the retrieval requirements, engineers will have more time to investigate retrieval failures and work with business experts on exceptions the system still handles poorly.
How does 4Minds reduce repeated implementation work?
4Minds reduces repeated implementation work by automating recurring data preparation and updates. Our platform’s ingestion process preserves source context, such as section headings and table field definitions, and continually makes new or revised content available for retrieval once it’s indexed.
Our platform builds a GPU-accelerated knowledge graph from the source data and records relationships between documents and records. Basic retrieval and verification, on the other hand, use those relationships to check whether retrieved passages agree, but agreement does not prove that passages are current or correct.
Model adaptation is a separate operation. Our select model adaptation updates selected trainable parameters while other weights remain frozen. New source content can become retrievable without waiting for that adaptation.
Engineers and business experts still need to define acceptance tests and decide whether the results justify deployment.
How can I design enterprise AI that is useful and accurate?
You can design AI that is useful and accurate by asking an engineer and business owner to review one workflow together in this way:
- Document the decisions the AI should support.
- Collect examples that expose common exceptions.
- Agree which errors would make the system unacceptable.
- Compare the proposed system against the current process before expanding its role.
- Automate routine updates.
- Keep testing the decisions that matter.
BCG's Applied AI Index 2026 describes leading companies as the ones that choose where AI creates value, then redesign workflows around those choices. The process I outline above is how you get there.
FAQs
Who should design enterprise AI?
Engineers and business experts should design and define enterprise AI together, then include security and legal specialists when data access or permitted actions affect the design.
Why don’t standard components guarantee a competitive advantage for AI?
Standard components don’t guarantee a competitive advantage for AI because that kind of competitive advantage depends on how the AI system uses its data to support specific decisions and how well it performs against business requirements.
Which skills do engineers need to implement production LLMs?
Engineers implementing production LLMs need to understand prompt formatting and data leakage, how to evaluate retrieval, and how to test model behavior on unfamiliar data. General software experience does not cover every failure mode for LLMs.
How can I free engineering time for AI development?
You can free engineering time for AI development by automating repeatable ingestion and index updates. Engineers remain responsible for evaluating changes and resolving failures that require knowledge of the application.
Does 4Minds automate repeatable ingestion and index updates?
Yes, 4Minds automates ingestion and graph construction, then provides retrieval and model adaptation. With 4Minds, retrieval uses indexed content, and adaptation updates selected trainable parameters.
