AI operations and governance
Production AI needs an operating model, not only a provider key. Kumiko Enterprise keeps the controls close to the tenant, policy, handler, and audit boundaries of the application.
The operating loop
Section titled “The operating loop”- Configure a provider and its secret for the tenant.
- Define the prompt and step defaults in code.
- Tune tenant policy or prompt revisions without changing the pipeline structure.
- Evaluate with mock responses and golden fixtures before activation.
- Activate or roll back the revision explicitly.
- Inspect provenance, token usage, provider, model, and prompt revision.
- Review executed writes in the normal audit path.
The main controls
Section titled “The main controls”| Control | Where to start |
|---|---|
| Provider and model selection | ai-foundation and provider reference |
| Prompt history and rollback | prompt-store |
| Draft, activate, and rollback | ai-pipeline |
| Token and transcription budgets | The Assistant and cap-counter |
| Recorded run facts and cost | Provenance and cost control |
| Launch evidence | Production AI governance |
What to persist
Section titled “What to persist”Provenance can record identifiers and accounting facts such as provider, model, prompt revision, and token usage without storing the resolved prompt or model response. The in-memory step result still needs the application’s data classification before it is persisted or logged.
Assistant conversations and tool calls are application data. Apply the same field access, retention, export, erasure, secret handling, and backup rules as for other tenant and user data.
Build your own operations layer
Section titled “Build your own operations layer”You can implement a smaller policy entity, evaluation runner, or audit report with public Kumiko features. Enterprise packages the revision model, activation commands, golden fixtures, dry runs, caps, and provenance conventions so teams do not have to assemble those controls repeatedly.