Deploying business AI on your own cloud

Who owns what

You retain control of your cloud account and your business data. We use customer-owned accounts where the agreed services support them, and document the permissions and processors involved. Ownership of code, work products and third-party licences is defined in your agreement; different parts can have different terms.

Access follows the specific job

People and agents receive the access needed for the agreed job, not unrelated systems. For example, an intake workflow may read an approved inbox and prepare records without broad access across the company. You control access through the agreed, vendor-supported access and revocation process. The method and effect of revocation depend on the services involved; the operating plan records how access is reviewed and removed.

Where data lives and how it is handled

Customer-cloud deployment and external processing are distinct parts of the design. Some requests may pass to external model or service processors outside your cloud. We map those processors and document what information each handles before deployment, including the agreed data locations, retention and deletion arrangements.

• Where application data, backups and logs are stored, and the agreed regions.
• Which external processors receive information and for what purpose.
• What is recorded in logs, who may read them and how long they are kept.
• Retention, deletion and backup responsibilities for each relevant service.
• Encryption in transit, encryption at rest and managed-key arrangements supported by the agreed design.

Supported, documented connections

We use supported vendor APIs and OAuth for documented, maintainable connections. The access record identifies the account, permissions, processor and person responsible for each connection. Vendors can change APIs, permissions or revocation behaviour; ongoing support includes reviewing affected connections with you and agreeing the adjustment.

Security responsibilities and design references

Security responsibilities vary with the cloud services, integrations and agreed design. The cloud provider, your team and our delivery team each have defined responsibilities. We map the agreed controls to these references:

• AWS Shared Responsibility Model: explains the shared responsibilities between the cloud provider and the customer, which vary with the selected services and integrations.
• NIST Cybersecurity Framework: a reference for understanding and improving the management of cybersecurity risk.
• OWASP Top 10: an awareness reference for common web-application security risks.

Day-to-day operations

After launch, monitoring checks that the system is doing its job. The operating routine includes reviewing access, checking AI and infrastructure costs, handling exceptions and improving the workflow as the business changes. We agree the ongoing support responsibilities and quarterly AI training so the team can use the system confidently.

Frequently asked questions

Sources and design references

• AWS Shared Responsibility Model
• NIST Cybersecurity Framework
• OWASP Top 10