An AI partner should be able to explain the work they will build, the boundaries around it and the evidence your team will receive. A fluent demonstration and a list of model names do not answer those questions.
For regulated work, involve the people responsible for the process, security, privacy and professional decisions before the delivery scope is fixed.
Ask for a concrete architecture
Request a description of the data sources, model processing, retrieval, tools and records. Identify which system owns each authoritative value and how external changes are authorised.
Ask where information may be stored or transmitted, including diagnostics, backups and evaluation datasets. “Private” or “sovereign” is not a complete answer without an actual data-flow and operating explanation.
Hosting choices should follow your requirements. On-premise infrastructure does not establish compliance by itself, and a hosted service is not automatically unsuitable. The provider’s terms, controls and role in the processing matter.
Make the proposal separate claims from evidence
A partner may describe a capability, an illustrative example or a completed project. Those are different kinds of statements. Ask which one you are seeing and what can be independently reviewed.
For performance claims, request the task definition, test population, measurement period and exclusions. A benchmark from another organisation is not a forecast for your workflow.
Respect confidentiality, but expect a clear explanation of the partner’s role and the evidence they can legitimately share. Do not treat a confidential project name as a substitute for a testable delivery plan.
Examine the evaluation method
Ask how representative tasks will be selected and which cases must not be automated. Include incomplete inputs, conflicting sources, unauthorised requests and external failures.
Separate model quality from application controls. A good extraction score does not prove correct permissions. A valid output schema does not prove that a number came from the right source.
The acceptance decision should identify who reviews the evidence and what remains outside the tested scope. No evaluation establishes that every future output will be correct.
Inspect the human decision boundary
For work requiring professional judgement, define what the software prepares and what the authorised person decides. Ask what information is shown before approval and whether approval is bound to the exact proposed action.
Check what happens when a reviewer is unavailable, a proposal changes or an action cannot be reversed. A generic “human in the loop” label is not sufficient detail.
The Ryzolv Harness Rules explain our approach to proposal, validation, traceable calculations and named-human approval. They are engineering rules, rather than a certification that every legal obligation has been met.
Agree operating responsibility
Clarify source-code and configuration access, support boundaries, model-provider dependencies and handover materials. Establish who handles incidents, access revocation and changes after launch.
Ask how the system can be stopped, how affected records are identified and which changes can be rolled back. A kill switch may prevent new work without undoing changes already committed in a connected system.
Costs should include usage, integration maintenance and review effort. Avoid a delivery or savings promise that has no relationship to the scope.
Use legal requirements accurately
A voluntary framework, an internal policy and a law are not interchangeable. The NIST AI RMF can help organise risk management; it is not an approval issued by a regulator.
Legal applicability depends on the organisation, use case and role. For example, the EU AI Act distinguishes obligations across actors and categories rather than applying the same controls to every application.
Your legal and professional advisers determine the applicable obligations. An engineering partner should help translate agreed requirements into controls and evidence without claiming to replace that judgement.
A useful next step is a scoped conversation about one process. Our AI Engineering page describes the capabilities available for that work.
Written by Anshul Kaushik, Managing Director at Ryzolv.
Back to Insights