Technology
Enterprise AI
Choose model, retrieval, evaluation and control patterns according to task risk, data rights, human authority and production observability.
Page purpose
Evaluate Enterprise AI by architectural fit and operating consequence, not popularity.
AI technology introduces probabilistic behavior whose engineering boundary must be narrower than its apparent capability. Pattern and model selection follow task form, error consequence, language, latency, privacy, explainability, data rights, cost and deployment constraints.
Predictive, retrieval, generative and agentic patterns expose different uncertainty and authority. Architecture must separate model output from system action, version the model, prompt and context as one evaluated configuration, and provide fallback when confidence or dependencies leave the accepted envelope.
Fit criteria
Criteria to prove before adoption.
- Is AI materially better than a deterministic or process-based alternative for this task?
- What error is tolerable, who detects it and who retains decision authority?
- Which data may be used for input, retrieval, evaluation, logging and improvement?
- Which model boundary and deployment option fit privacy, latency, cost and exit needs?
Intended role
The role the technology should perform.
- A bounded AI component with explicit input, output and action authority.
- A versioned configuration whose behavior can be compared across representative cases.
- Designed uncertainty, fallback and human-decision semantics.
- Observable quality, latency, resource use and data exposure over change.
Engineering patterns
Decisions that make the choice operable.
- Pattern and model-boundary decision record with quality attributes and excluded authority.
- Data-flow design for input, retrieval, context, isolation, logging and deletion.
- Versioned evaluation harness with representative, multilingual, edge and adversarial cases.
- Inference and action architecture defining confidence, validation, fallback and human control.
- Change and telemetry schema linking model, prompt, context source, output and downstream action.
Controlled adoption
Proving fit before scaling.
- Classify the task and compare deterministic, retrieval, predictive, generative and agentic patterns.
- Constrain data and action authority before comparing model or deployment options.
- Create the evaluation distribution and failure taxonomy before tuning the configuration.
- Design validation, human control and fallback at the point where output can affect state.
- Version every behavior-changing dependency and re-evaluate when the task, data or model changes.
Technology limits
When does complexity exceed value?
- Confident but incorrect output influencing decisions beyond the approved scope.
- Sensitive data exposure through inputs, retrieval, logs, model providers or generated content.
- Automation bias, uneven language performance or inaccessible review interfaces.
- Uncontrolled model, prompt or source changes invalidating earlier acceptance evidence.
Operating signals
Signals of a production capability, not a demonstration.
- Quality distribution and worst material error classes across representative cohorts.
- Calibration, abstention and fallback behavior at the accepted operating threshold.
- End-to-end latency and resource consumption by context size and task class.
- Behavioral regression after model, prompt, retrieval or policy changes.
Decision questions
Engineering questions before choosing a tool.
What determines the boundary of an AI component?
The boundary follows the task, permissible data, consequence of error and authority to change system state. Model capability outside that boundary remains unavailable to the workflow.
How much evaluation is enough?
Evaluation must cover the accepted operating distribution and material failure classes, with sample depth proportional to consequence. It remains a recurring gate because models, context and real inputs change.