Within agreed rules
Prepare the permitted next action using approved data and scoped access.
Example: update a routine status recordTrust & governance
Clear boundaries. Visible accountability.
Know what the automation can do, who can approve an exception and where your data goes. These decisions are agreed before production access is enabled.
Controls statement reviewed 4 September 2026. Exact deployment commitments are defined in the signed project documents.
Current posture
Readiness, stated precisely.
We publish the status we can support today, so your procurement team can assess the requirements early.
SOC 2-readyGDPR-readyHIPAA-ready
These are readiness statements, not certifications.
SOC 2-ready, GDPR-ready and HIPAA-ready describe a control posture. They do not mean a current independent audit report exists. If your procurement process requires a SOC 2 Type II report or ISO 27001 attestation, raise that requirement on the first call. Readiness does not replace signed project terms or your legal assessment.
The automation boundary
Three paths. No hidden authority.
Every workflow has a signed decision boundary. This example shows how routine work, judgement calls and prohibited actions are separated.
A request reaches the workflowIllustrative control design
Needs a person
Pause at the decision point and route the context to a named human owner.
Example: resolve a sensitive customer exceptionOutside the boundary
Do not proceed. An automation cannot grant itself permission to go further.
Example: override an agreed business policyKeep an agreed record of the action, approval or blocked attempt for review.
Before production data is enabled
Four decisions become part of the record.
Each one has a named document and an accountable owner. They form the basis for acceptance and ongoing operation.
Data, systems and region
Architecture and data-flow specificationThe data categories, source and destination systems, processing region and approved access path.
Providers and credentials
Access model and sub-processor disclosureThe providers involved, who owns each account, the permissions granted and how your team can revoke access.
Decision rights
Signed automation boundary matrixWhat runs within agreed rules, what needs a named approver and what the system is never authorised to do.
Acceptance, change and exit
Pilot acceptance pack and project MSA/SOWTest evidence, monitoring, escalation and change control, along with the dependencies needed for continued operation.
Your company retains responsibility for business policy, authority to act in its systems and the legal basis for processing personal data or contacting people. For outbound work, channels, scripts, consent evidence, calling windows, opt-outs and escalation are agreed before launch.
Data & access
Make the operating conditions explicit.
From ownership to model changes, these commitments are reflected in the MSA, statement of work and project records.
United Arab EmiratesUAE / GCC in-region, or EU
AustraliaSydney region, or EU
United StatesUS region
IndiaIndia region
Region options are confirmed for the exact deployment before signature, together with cross-border access and support conditions. Our delivery team is in India; in-region restrictions require an agreed access design, which may include de-identified data or an in-region environment.
Your ownership and exit route
You own the workflows, prompts, configuration, documentation and outputs created for the project. Continued operation depends on the third-party accounts, licences, hosting and data sources named in the project documents; we do not withhold deliverables.
Scoped access, not shared admin accounts
Each automation is designed for least privilege, with only the permissions its workflow needs. We review the access model with your team and document the credential-revocation route.
Data use and provider visibility
Processing regions and sub-processors are disclosed before signature. Data-use terms, including any applicable provider no-training term, are recorded before production data is enabled. Sub-processor changes are notified.
A named human owner for exceptions
Approval queues, value thresholds, retry limits and escalation triggers are configured for the workflow. The exception goes to an accountable role, not an unowned inbox.
Logging and evidence before go-live
Logging requirements are agreed and tested in the working workflow. Tracing, outcome tagging and monitoring make it possible to inspect what ran, what escalated and what failed.
Controlled model and workflow changes
We record the model serving each workflow, retain an evaluation suite and test material changes before production. Work outside the signed automation boundary needs written approval.
Public group documents
Start your due diligence here.
These policies describe the group baseline. The project agreement and data terms define the exact deployment.
Have a security questionnaire? Send your SIG, CAIQ or internal format to hello@ravan.ai. We can review requirements before you invest time in scoping.