Useful AI needs clear boundaries.
We agree how an AI system may act, what information it may use and how its results will be evaluated before production use. The controls are recorded in the project scope. This page is the reference the service and product pages follow.
One approval policy, three situations.
Human review, automatic validation and an audit log are different controls. The scope says which applies to each step, and these are the defaults.
A person approves consequential actions
During a first pilot, consequential actions such as sending a message or writing to a business record wait for a person to approve them. Validation rules can run automatically, but passing a rule is not approval.
Automatic actions, agreed per action
After the evaluation, automatic actions can be agreed per action, with validation rules, logging and exception handling written into the scope. Each automatic action is logged with what was done, when and on what basis.
Product-specific settings
Our products have their own review settings, described on each product page. Rezule keeps approval on by default; review can be turned off only account by account, on purpose, and every change is logged. COQA.ai runs only approved cases. EduVoice treats every weekly plan as a draft the parent approves, and AI-suggested evidence stays a suggestion until a parent confirms it.
Build trust into the work itself.
These are the delivery principles we use to shape a project proposal. The controls and responsibilities for a specific implementation are agreed in its scope.
Define the job
Agree what the system should do, what it must not do and when a person should review or stop an action.
Evaluate the outcome
Use expected and difficult cases to examine usefulness and failure behaviour. Report limitations alongside results.
Map the information
Identify necessary data, processing providers, access permissions and proposed retention arrangements.
Make responsibility visible
Agree who reviews exceptions, operates the system, monitors usage and maintains integrations.
Assess the actual requirements
Privacy, security and sector requirements depend on the use case and jurisdiction. Involve the responsible stakeholders before production use.
What applies unless your policy says otherwise.
Defaults can be tightened to your policy. They cannot be loosened silently.
Defaults
- Client data is not used to train models. Provider settings that would allow it are switched off in scope.
- Data is processed only by the providers and in the region named in the data map. Hosting region and model provider are chosen per project, and we confirm the combination is feasible before proposing delivery.
- Access follows your existing permissions; the assistant cannot see what the user cannot.
- Prompt and output logs are kept only as long as evaluation and debugging need them, for a period agreed with you.
- Uploaded documents and extracted records are retained only as long as the workflow needs them, for a period agreed with you.
- Review queues are designed and tested so that cases the system flags as uncertain go to a person. The evaluation reports how often that happened and what slipped through.
- Credentials are held in a secrets store, never in code or prompts.
One commercial policy, quoted everywhere.
Ownership, licences and handover are agreed before development starts. Bespoke code written for you is yours under the engagement agreement; third-party components keep their own licences, and infrastructure and accounts are arranged in scope.
Where the same sentences appear
- Services and audience pages quote this page rather than restating it.
- Product pages state their own review settings and link to product-specific data information.
- Articles use the same phase names and durations as the approach page.
Before we begin.
Which actions need a person to approve them?
During a first pilot, consequential actions such as sending a message or writing to a business record wait for a person to approve them. After the evaluation, automatic actions can be agreed per action, with validation rules, logging and exception handling written into the scope. Our products have their own review settings, described on each product page.
Will our data be used to train models?
No. Client data is not used to train models. Provider settings that would allow it are switched off in scope.
Who can see our documents?
Only the people and services named in the scope. Access follows your existing permissions, and the review interface shows which sources an answer used.
What happens when the AI is unsure?
Review queues are designed and tested so that cases the system flags as uncertain go to a person. The evaluation reports how often that happened and what slipped through.
Where is our data processed, and is it used to train models?
Data is processed only by the providers and in the regions agreed in scope. Client data is not used to train models. Provider settings that would allow it are switched off in scope. Retention, access and logging are written into the scope.
Who owns the code and the solution?
Ownership, licences and handover are agreed before development starts. Bespoke code written for you is yours under the engagement agreement; third-party components keep their own licences, and infrastructure and accounts are arranged in scope.
Have specific delivery requirements?
Bring them into the conversation from the start. They shape the scope, not the price of an afterthought.