Ownership & Security
Know what your AI
can access.
Before AI can act on your business, you should know what it can access, where your data goes and who can stop it. We work through those decisions with you before launch.
This page explains our approach. The architecture and agreements for your build define its specific controls.
A system you own.
Your system is built in accounts you own, with access and billing under your control. At handover, you receive the agreed code, configuration and operating documentation.
- Your accounts and data
- You control the hosting, model and connected-service accounts used for your build. Your business data and content remain yours.
- Access for the work
- You grant Vulc access for delivery. Handover defines what is removed and any access retained for optional support, with a way for you to revoke it.
- Independence after handover
- You can run and develop the delivered system independently of Vulc. Hosting, model usage, third-party licences and maintenance still need an owner and budget.
The build agreement defines the delivered rights and any reusable components or third-party licences.
How delivery and handover workKnow where your data goes.
Connected tools and AI providers can receive data needed for the work. Your data-flow map identifies those services and what each one processes.
- Information sent to AI
- We identify the records a task needs and what to exclude. A support reply might need the enquiry, order status and returns policy.
- Storage and location
- The review covers application hosting, databases, model processing and connected services. An EU database region alone does not keep every data flow in the EU.
- Retention and deletion
- Working records, logs, backups and provider-held data need retention and deletion rules. Deleting a source record may leave copies elsewhere.
Can an AI provider train on our data?
It depends on the provider, product and agreement. For example, Anthropic’s commercial terms state that it does not train models on Customer Content. Retention is a separate question and varies by feature and agreement. We check the services selected for your build.
Choose what AI may do.
Permissions are defined by workflow and connected tool. You decide which actions need a person and which may run automatically within agreed limits.
For example, refunds could require individual approval or run within an agreed policy. We check how the integration and application can enforce those limits, including the access the connected platform allows.
Connecting your toolsPlan for mistakes and interruptions.
AI can produce incorrect answers, and connected services can fail. The launch review needs to cover what happens when the expected path breaks.
- Test before release
- Review permissions, approvals, incorrect inputs, failed connections and repeated requests. Agree acceptance criteria and who authorizes go-live.
- Make actions traceable
- Specify the activity and approval records needed to investigate a problem, who can access them and how long they stay. Logs can contain personal data too.
- Stop and recover
- Document how to pause work, revoke access and handle queued actions. Agree backup coverage, recovery testing and rollback limits: restoring a database cannot unsend a message.
- Name the responsible people
- Assign incident contacts and responsibility for monitoring, fixes and updates. Ongoing Vulc support is optional; coverage and response commitments belong in the support agreement.
Security you can assess.
Vulc does not hold security certifications. A provider’s certification covers its stated scope; it does not certify Vulc or the application built on that provider.
Your review should cover the application’s configuration, access, credentials, encryption and operating responsibilities. Bring any audit requirements or response commitments into the discussion before scope is agreed.
What about GDPR and sensitive data?
The data, purposes, providers and processing locations determine the review needed. The parties must agree their responsibilities and any required data processing agreement before access to personal data. Regulated or particularly sensitive workflows need assessment before they enter scope.
Client-owned accounts or an EU hosting region alone do not establish GDPR compliance. Our privacy notice explains website enquiries; your engagement documents cover processing for your build.
Review the details before you commit.
Ask for the security overview or bring your own questionnaire. Your technical or legal team is welcome in the review. Project-specific documents are prepared around the proposed build.
- Architecture overviewAccounts, providers, regions and deployment.
- Data-flow mapInformation sent, stored, retained and deleted.
- Permissions mapAllowed actions, approval rules and exclusions.
- Operations and handoverTesting, incident contacts, recovery and access.
- Data processing agreementApplicable roles and terms, reviewed for the engagement.
Describe your concern without sending passwords, API keys or customer records. We can arrange an appropriate way to share further information.