Defined scope
Access map before connection
The scope names each system, credential, permission, and person that needs access before anything is connected.
FollowAI / trust boundary
Trust starts witha visible boundary
We do not use certification logos or universal security promises we cannot prove. Each build documents the data, providers, permissions, approval points, ownership, and handover that apply to that system.
Requirements before accessProvider terms verifiedHuman approval where neededRevocable handover
Control boundaryDefined before access is granted
Data path documented
Permissions scoped
Sensitive actions identified
Ownership and handover written down
System controls
Questions answered inside the architecture
These are design requirements to confirm for each deployment—not claims that every vendor or environment behaves the same way.
Provider dependent
Credentials stay revocable
The deployment plan prefers scoped service accounts or provider authorization that can be removed without sharing a personal password.
Approval gate
Sensitive actions can stop
Customer messages, payments, record deletion, and other consequential actions can wait for a named person to approve them.
Data map
Data use is written down
Sources, destinations, retention, model providers, and deletion responsibilities are documented for the selected system.
Tool dependent
Important runs leave evidence
Where the connected tools support it, the workflow records inputs, actions, errors, approvals, and the resulting state.
Scoped choice
Deployment follows the requirement
Cloud, client-owned infrastructure, and local-model options are evaluated against the actual data and operating constraints.
Control map
Five boundaries to approve before launch
The written control map travels with the technical scope.
Data
What enters, where it travels, and what may be retained.
Access
Which person, service, or model may read or change it.
Approval
Which actions stop for a named person.
Ownership
Who owns credentials, workflows, exceptions, and decisions.
Evidence
What the selected tools can record about a run.
Trust FAQ
Questions to answer before access is granted
Is my data used to train a model?
That depends on the selected provider, account type, and settings. Before launch, the scope identifies every model provider and documents its applicable data-use and retention terms.
Who at FollowAI can see my systems?
The access list is agreed for the build and support scope. We prefer named, revocable accounts and remove FollowAI access at handover or when support ends.
What happens if we stop working together?
Handover, credential revocation, export, and deletion responsibilities are written into the project scope. What remains running depends on the accounts and infrastructure selected for the build.
Can the AI act on its own inside our systems?
Only actions explicitly included in the workflow should run automatically. Sensitive actions can be held for approval, and the boundary is reviewed before launch.
Can you meet our legal or procurement requirements?
Send the requirements before access is granted. We will identify what the proposed architecture supports, what requires a different vendor or deployment, and what FollowAI cannot honestly promise.
Next step
Define the control boundary before the build
We will map the data, providers, permissions, approval gates, ownership, and handover requirements with the workflow itself.