Your AI keeps changing. Who reviews it?

No. Triggers and approvals are defined. New data may be unsuitable; an updated version must pass the agreed comparison.

Yes, after a current-state review of permissions, data paths, versions and testability. Missing foundations are added in a targeted way before the pilot is taken into production.

After the pilot, data, models and requirements keep changing. OTOKO® sets up versioning, approvals, monitoring and controlled updates for your AI applications. Your team knows which version is running, how its quality was assessed and how to roll back if problems occur.

Link model, data and configuration versions to approvals Set up automated quality tests before every deployment Monitor data drift, response time and resource consumption Compare updates against the production version Provide an AI inventory and technical documentation for the review bodies responsible in your case

Operating model with roles and runbooks Monitoring with alerting Version overview and technical review documentation

For classic models, we link code, data version, feature definitions and the model artifact. For generative applications, the prompt, search index, tools and model configuration are added. A model registry records approvals and responsibilities. Credentials are not distributed with the artifacts. Development and production environments receive separate permissions. This makes it possible to review changes and, in the event of incidents, reconstruct the components actually deployed, rather than just looking at the last known source code.

Technical availability says little about answers that are wrong in substance. We combine measurements of response time, errors and consumption with suitable quality feedback. Data drift is an indication of changed inputs, but not yet proof of worse results. Retraining or a model change is therefore evaluated against a stable test set. A staged rollout limits the impact; fallback versions and shutdown options are prepared. For external models, we take version changes and provider outages into account.

The scope of operations specifies hours, escalation paths and responsibilities for technical and business incidents. Release owners decide on the quality of new versions. The handover includes runbooks, a version overview and documented limitations. For data protection and any relevant AI requirements, we provide technical information to the responsible bodies; operation alone does not establish legal compliance.

We build the path from experiment to managed model operation. Data versions, training runs, artifacts and approvals are connected so that a production decision remains traceable even after a model change.

A production model version can be reproducibly identified. A failed quality check prevents publication. Rollback and restart are tested in practice.

Example: A demand forecast is retrained monthly. The new version is first checked against fixed reference periods and current business results. Only an approved combination of data processing and model goes into production; the previous combination remains available as a fallback.

A notebook often contains implicit assumptions about files, libraries and manually executed steps. We turn the relevant processing steps into reproducible pipelines with recorded dependencies. Model artifacts receive a unique version and a reference to their training, configuration and evaluation. Registration alone is not yet a release. We define which quality, security and operational checks must be passed before publication. Business assessment and technical deployment remain distinct, so that a technically working model does not go into production without a content review.

In operation, we monitor availability, response times and changes in the input data. A changed data distribution is a reason to investigate, but not yet proof of worse predictions. Where business outcomes only become known later, we plan for feeding them back into the quality assessment. Model changes happen with an agreed comparison and fallback path. Depending on the use case, shadow evaluations or limited user groups can make sense at first. If a model is rolled back, its associated preprocessing and interfaces must also match up. Your operations team receives instructions for incidents, redeployment and the escalation of business anomalies.

Prioritized list with benefit and effort Business unit, IT, data protection, OTOKO® Data Architect Assessed use cases, data map, regulatory classification

Data architecture, modeling approach, governance Business unit, architecture, information security Target architecture, operating model, success criteria, data protection concept