Security & Trust

Build customer growth on a foundation you can evaluate.

Customer intelligence and AI involve information that matters to your business: customer records, interactions, commercial processes and access to connected systems. Before deploying them, your team needs clear answers about how the proposed solution will operate.

Pobuca works with customers and their technical teams to review the architecture, data flows, access model and operating responsibilities of an implementation. Security is part of that design — not a badge that replaces the discussion.

Discuss your security requirements
Bring your procurement questionnaire, architecture standards or project-specific requirements to the discovery meeting.

On this page

Azure-based delivery, with security built into the project

Pobuca delivers its projects on Microsoft Azure and operates an ISO/IEC 27001-certified information-security management system. Cloud infrastructure and information-security management are foundations; the actual solution also needs appropriate access, integration and operational controls.

We define those controls around the data and actions involved: authorised identities, access permissions, protected connections, confidential handling, logging, separation of customer information and appropriate recovery arrangements. Azure capabilities are selected and configured for the solution; a platform badge is not a substitute for reviewing the implementation.

Responsible use of AI

Our delivery and governance processes address applicable GDPR and EU AI Act requirements through the scope of the use case, documented data handling and appropriate human oversight. AI agents act within agreed permissions and business rules. Sensitive decisions and exceptions follow the agreed approval or handover path.

Requirements depend on how a system is used. We do not present cloud hosting or certification as a blanket guarantee that every possible customer use is compliant.

Know where the data goes

Hosting, storage, AI processing and connected providers are described for the agreed architecture. Processing locations and any authorised international transfers are addressed through the relevant agreement and safeguards. We do not assume that one Azure region automatically describes every external service, integration or model involved.

Understand the actual deployment

The relevant questions depend on the product, integrations and hosting arrangement. Identify where customer data is stored, which services process it, how information moves between components and who operates each part.

For an AI implementation, that includes the agent service, knowledge sources, model services, connected business applications and any channel providers. Hosting one component in a particular location does not by itself answer where the complete workflow processes data.

We use the proposed architecture as the basis for the security conversation, rather than assuming every Customer Intelligence or Zemark deployment is identical.

Give people and agents the access they need

A marketing operator, service representative, administrator and AI agent do not necessarily need the same information or permissions.

The access design should identify roles, identities and permitted actions. An agent that prepares a customer brief may only need read access. An agent that updates a record needs a defined write scope and the appropriate validation.

Customer-facing information should be distinguished from internal notes and restricted commercial material. The same principle applies to a knowledge base: information useful to an employee is not automatically suitable for an external answer.

Define control before enabling action

Automate and Zemark are intended to work within agreed processes. Decide which actions may run automatically, which require approval, and which must be referred to a person.

A useful approval shows the proposed change and its context. A useful handoff gives the receiving team the information it needs to continue. For important business actions, the implementation must also make the resulting system state visible.

This supports practical control over the workflow. It is not a claim that AI outputs are infallible or that a human review can be removed from every process.

Make knowledge and customer information accountable

Identify the owner of each knowledge source and the process for reviewing changes. Product information, policies and customer instructions can become outdated; the system needs a way to receive approved updates.

Conversation history and personal data require their own rules for collection, permitted use, retention and access. Those rules should reflect the client's purposes and the actual implementation, including any reporting or knowledge-improvement process.

Do not treat every interaction as material that can automatically be reused in a public answer. The knowledge workflow and the privacy review need to agree what may be retained, extracted and published.

Plan for operation, not just launch

Ask how incidents and access issues are escalated, how changes are tested, and which party maintains each integration. Discuss backup and restoration arrangements, monitoring and continuity expectations for the components in scope.

A connected workflow depends on more than one system. Its operating plan should consider unavailable sources, failed business actions and the fallback for the customer or employee.

Service levels, recovery objectives, support coverage and responsibilities belong in the agreed documentation. They should not be inferred from a general statement that a solution runs in the cloud.

Support your due diligence

Relevant security and contractual material can be reviewed as part of procurement. Depending on the engagement, this may include an architecture description, data-processing responsibilities, access requirements, applicable third-party services, and available assurance documentation.

The scope and validity of any certification or assessment must be checked against the entity and service being procured. Likewise, the security features of an underlying cloud platform should not be presented as though every implementation automatically uses every feature.

Our aim is to make the discussion specific enough for your technical, security and business teams to make an informed decision.

Questions worth resolving before a pilot

Start with the data the pilot genuinely needs. Agree who can access it, whether realistic synthetic data is sufficient for early tests, what the agent may do, and what evidence will demonstrate correct operation.

Test a successful request, an ambiguous request, an unavailable system and a request outside the agent's authority. Review what the customer sees and what your team can inspect afterwards.

A useful pilot validates operating boundaries as well as the attractive use case.

Does every implementation use the same hosting and model services?

Pobuca projects are delivered on Microsoft Azure. The exact architecture, services and model-processing arrangements depend on the agreed solution.

Can our team review the proposed architecture?

Yes. That review is an important part of defining an enterprise implementation and its responsibilities.

Does using AI mean giving an agent unrestricted access?

No. Access and actions should be limited to the purpose and permissions defined for the workflow.

Are service levels and certifications listed here universal commitments?

Pobuca operates an ISO/IEC 27001-certified information security management system. Project-specific service levels and assurance evidence are provided and agreed for the service you are procuring.

Evaluate the technology and the operating model together. Book a discovery meeting.