Clear boundaries before access.

During strategy work, Kriaka uses representative evidence needed to understand the decision. This may include existing documents, targeted conversations, examples of real work and read-only walkthroughs inside the agreed boundary. The aim is decision-sufficient evidence, not exhaustive collection.

Implementation requires a separate scope and data-handling boundary. Kriaka connects to or imports only the information required for the authorised work.

The customer approves each connection, permission and allowed use. The boundary distinguishes between reading information, preparing work, recommending an action and carrying it out.

A connection being technically available does not give Kriaka authority to use it. Write-capable actions remain draft-first or approval-gated unless the signed scope explicitly allows a narrower action after testing.

The customer's business systems remain the authoritative record. People retain judgement over consequential external, financial, legal, employment, safety and binding actions unless narrower authority is separately agreed, tested and documented.

Every operating scope names the human reviewer, escalation path and actions the system must refuse or return for a decision.

Approved AI, hosting, authentication, integration, search and business-system providers may process information needed to deliver the agreed work. Processing may occur outside New Zealand.

Kriaka does not promise a fixed provider, New Zealand-only processing, zero retention or a certification unless the specific deployment supports that claim. The relevant provider information and data-handling terms are confirmed before production work.

Within each agreed scope, Kriaka uses customer-specific accounts, credentials and operating areas. Access is limited to the people, systems and permissions required for that scope.

Before real customer data is used, the data source, purpose, reviewer, retention posture, backup path, incident response and offboarding path must be named. A connection is not considered ready merely because authentication succeeds.

Production readiness includes testing normal work, missing information, unsafe actions and edge cases. It also requires monitoring, a named escalation path, recovery procedures and the ability to stop or disconnect affected work.

Kriaka does not promise that failures cannot happen. The responsibility is to make the operating boundary, evidence and response visible enough to contain and recover from them.

Access can be revoked and connected tools can be disconnected. Customer information is returned, exported or deleted according to the signed scope, the Privacy Policy and applicable legal or accounting retention obligations.

Continued Kriaka management is not required. Transfer, internal ownership, another provider or stopping are valid outcomes when the evidence supports them.

The engagement agreement, data-handling schedule, approved access record and provider information govern the exact customer scope. The Privacy Policy explains Kriaka's general handling of personal information.

If your business has a specific residency, provider, accreditation, self-hosting or external-processing requirement, raise it early. Kriaka will confirm whether the requirement can be met rather than inventing a deployment path to preserve the opportunity.