Before integration starts, we document the data path: what the AI agent receives, who can enter the working environment, where storage sits, and when copies are deleted. These terms enter the specification and contract, giving the customer a clear access boundary before launch.
We select the architecture after reviewing the customer's systems and data categories. Specific services, hosting regions, roles, backup rules, and retention periods are recorded before production data is transferred.
The AI agent receives the fields required for the agreed workflow: message text, knowledge-base material, request status, and selected data from the CRM or another connected system.
Before launch, we map every data flow and remove information the agent does not need. Passwords, payment details, medical information, and other sensitive categories require separate approval and protective controls.
We place production data in the customer's infrastructure or an agreed cloud or dedicated environment. The architecture records the hosting region, databases, backups, and exchange channels.
Development and production environments remain separate. Tests use anonymised examples or a purpose-built dataset whenever real information is unnecessary.
The stack depends on the workflow and the customer's constraints. Model providers may include OpenAI, Anthropic, Google Gemini, or Mistral; orchestration can use n8n or a custom backend, while PostgreSQL can hold structured data.
We connect CRM systems, Telegram Bot API, WhatsApp Business API, email, telephony, and internal services through approved interfaces. The specification lists every service that receives data and the purpose of each transfer.
Integrations use dedicated service accounts with minimum permissions, such as reading a required directory, creating or updating a lead, sending a message, or receiving a webhook event.
We request administrator rights only when a configuration cannot be completed otherwise. After connection, we reduce permissions, while the customer's system owner keeps control of accounts and keys.
Each project member uses an individual account and sees only the environment required for their task. Developer, administrator, and support roles stay separate, while critical-system actions enter an audit log.
Keys and passwords remain in a protected secrets store instead of documents or work chats. When a person's role changes or they leave the project, we revoke access and rotate affected keys.
Before development, we define the categories of personal data, the processing purpose, and permitted operations. We then reduce the field set, mask information in tests, protect transfers, and restrict the people who can view it.
The contract records the customer's and ZOLT's roles, legal grounds, hosting restrictions, and processing instructions under the law applicable to the project. Sensitive data may require an NDA, a dedicated environment, and human approval for critical actions.
Before the project closes, we provide the agreed code, configuration, documentation, and export of available data. The contract defines the transfer format and the materials included.
After handover, we close ZOLT accounts, revoke tokens, and delete working copies within the agreed period. Backups expire under the approved schedule, while any legal or contractual exception is listed separately.
During the audit, we list data sources, services, roles, and retention periods, then place the approved controls in the specification and contract.