Enterprise AI: start with the process, not the model

The conversation about enterprise AI often starts with the model: which reasons better, which costs less, which has more context, or which can call more tools. In a company, that decision comes later.

First we must define what operational result we are looking for, what information the system can use, what actions it can execute, what level of error is tolerable and what should happen when the case goes beyond what was expected.

1. A model is not a business system

A model can summarize, classify, extract, write up, compare or propose. To produce value repeatably you need an environment that turns that capability into a controlled operation.

That environment includes sources of truth, instructions, tools, permissions, user identity, validations, limits, activity logging, exception handling, and subsequent action.

A demo can work with a clean document and a well-formulated question. The operation must survive incomplete information, unexpected formats, contradictory data, different users, broken integrations, and situations that no one included in the demo.

AI brings capacity. The system converts that ability into a controlled result.

2. Start with a process metric

“Using AI” is not a business goal. “Reduce file classification time without increasing errors”, “prepare proposals faster while maintaining human review” or “detect requests that need attention before exceeding an SLA” are operational objectives.

Defines a primary metric and several guardrail metrics. If you optimize speed, watch quality. If you optimize autonomy, watch for exceptions. If you optimize cost, monitor customer experience.

3. Design eight layers before production

1. Objective

What result should improve and how will we know if it improved.

2. Trigger

What starts the system: a request, a document, a status change, a conversation, or a schedule.

3. Entry

What minimum data do you need and how do you validate that it is present?

4. Context

What sources you can consult, which prevails in the event of conflict, and what information you should not infer.

5. Reasoning

What cognitive task it performs: classify, extract, compare, generate, prioritize or decide within limits.

6. Action

What systems can you consult or modify. Reading a CRM and sending a payment are very different levels of risk.

7. Control

What needs approval, what thresholds exist and what conditions require stopping.

8. Observability

What is recorded to understand quality, cost, errors, decisions and behavior over time.

4. The source of truth matters more than the prompt

If a policy, price, customer status, or contractual document exists in multiple versions, the model cannot magically resolve an organizational contradiction.

Defines which repository is in charge, who maintains it, and how the current version is identified. If the system retrieves context from multiple sources, establish authorization priorities and filters.

AI can find information with great flexibility, but that flexibility is not a substitute for data governance.

5. Separate knowledge from action

A system that answers a question and a system that modifies the world should not be treated the same.

It is convenient to divide the architecture into two steps:

1. Determine what should happen.
2. Authorize and execute the action.

This separation allows you to apply deterministic validations, permissions, and approvals before touching data, sending communications, or executing transactions.

6. Don't ask “can you do it?”, ask “should you do it alone?”

The level of autonomy should depend on the cost of the error, reversibility, and the ease of detecting that something went wrong.

Human supervision should not be a decorative button. The supervising person needs sufficient context, authority to intervene, and a review load compatible with the volume.

7. Avoid “human approval” that can't work

If a person receives hundreds of AI-generated decisions and only has seconds to review them, approval can become a formality.

Design the review so that it shows the information necessary to decide: source, evidence, level of confidence when it exists, proposed changes and consequences of approving.

It also defines when a review is mandatory and when the system can act directly.

8. Manage risk according to impact and context

NIST's AI RMF framework proposes to manage AI risk continuously and contextually, considering impacts, roles, measurement, and governance throughout the lifecycle. NIST also recommends defining human oversight processes and mapping risks and benefits of system components.

In the European Union, the AI Act establishes specific requirements for systems classified as high risk, including risk management, data governance, documentation, records, transparency, human oversight, accuracy, robustness and cybersecurity. Not all AI systems are high risk; The classification depends on the use and the framework defined by the Regulation.

For a business project, a simple matrix can evaluate each action by:

• Magnitude of possible damage.
• Probability of error.
• Detectability.
• Reversibility.
• Data sensitivity.
• Impact on people.
• Legal or contractual obligations.

9. Define permissions with least privilege

The system should have only the permissions necessary for its function. If you need to read orders, you don't necessarily need to edit customers. If you prepare drafts, you don't necessarily need sendability.

When a tool allows sensitive actions, it introduces limits: maximum amounts, record types, allowed environments, authorized domains, or actions that always require approval.

10. Don't use the model for rules that may be deterministic

Validating email format, checking a maximum amount, verifying that there is consent or preventing an action after hours are rules that are usually more reliable as deterministic logic.

Use AI where it adds value: ambiguous language, flexible classification, text extraction, synthesis or decision support. Combine it with traditional software for limits and controls.

11. Evaluate behavior, not impressions

Before production, create a set of cases representative of the real work. Includes normal, ambiguous, incomplete, adverse and borderline cases.

For each case define what result is acceptable. The evaluation can measure:

• Classification accuracy.
• Correct extraction of fields.
• Compliance with rules.
• Use of authorized sources.
• Correct scaling.
• Quality of the proposed action.
• Latency.
• Cost.

It is not enough to ask someone if the answer “seems good.” A text can sound excellent and be based on the wrong data.

12. Test integration failures

The system must know what to do when an API is unresponsive, a credential expires, a database returns partial data, or a tool confirms an action late.

Design idempotence when there is a risk of duplicating actions, controlled retries, timeouts and intermediate states that allow you to know what was really executed.

13. Record enough to investigate

Observability should make it possible to answer: what input the system received, what context it used, what decision it produced, what tool it called, what result it received, and what happened next.

Not everything should be stored indefinitely. Log design must respect privacy, security and data minimization.

14. Control cost and latency as part of the product

A technically correct flow may not be viable if it takes too long or costs more than the value it produces.

Measures cost per case and latency distributions. Look especially at complex cases, because they tend to consume more context, more calls, and more tools.

Then decide where to use a more powerful model, a smaller one, deterministic logic or cache.

15. Design the operation after launch

AI does not eliminate maintenance. It introduces a new layer that also changes over time.

16. Version prompts, tools and evaluations

If you change instructions, model, tools or sources, the behavior of the system changes. Treat it as a new version.

Run the evaluation suite before production and compare results. This reduces invisible regressions.

17. Difference between model failure, process failure and data failure

When an output is incorrect, classify the cause. If the model did not understand an instruction, the solution is different than if the source contained an obsolete price or if no one had defined what to do in that case.

This taxonomy avoids trying to fix all problems by modifying the prompt.

18. How to choose the first use case

Look for a repeated, measurable situation, with accessible data and controllable cost of error. There must be a baseline and a person who can validate the result.

A good first case usually has:

• Sufficient volume.
• Observable result.
• Data available.
• Reversible or monitorable action.
• Manageable exceptions.
• Benefit that can be measured.

Additionally, it should generate reusable capabilities: authentication, data access, evaluation, observability, exception handling, and controls.

19. Architecture example: request classification

Hypothetical example: A company receives requests by email and form. The goal is to classify them and assign them to the correct team.

1. The system receives the request.
2. Validate that minimal information exists.
3. Consult an authorized source to identify client or contract.
4. AI classifies intent and priority.
5. Deterministic rules validate that priority does not exceed limits without evidence.
6. Low confidence cases are sent for review.
7. Normal cases are created in the ticketing system.
8. The result and final classification are recorded.
9. Human corrections feed future evaluation.

AI is just step 4. Business value depends on the entire system.

20. Signs that you are not ready yet

• There is no source of truth.
• You cannot explain what result means success.
• Nobody owns the process.
• The organization does not know which actions require approval.
• There is no way to detect errors.
• The case depends on data that cannot be reliably accessed by the system.
• The only argument is “the competition is using AI.”

Conclusion

The advantage of a business system with AI does not come from choosing the flashiest model. It comes from integrating probabilistic capacity within a clear process, with authorized information, limits, permits, supervision, evaluation and operation.

When those elements are designed, changing models can be a technical decision. When they are not, no model fixes the lack of process.

Official sources and references

• NIST—AI Risk Management Framework.
• NIST AIRC—AI RMF Core, including practices on human supervision, risk mapping and controls.
• NIST—Generative AI Profile.
• European Commission — structure of the AI Act, requirements for high-risk systems and related obligations.
• European Commission — guide on obligations of suppliers and deployers.

This article explains design and operation criteria; It is not a substitute for legal advice to determine specific obligations under the AI ​​Act or other regulations.

If you want to see how we structure the analysis before implementing a system, see how we work.