Privacy and control

Requirements to settle before deployment

These are proposed operating boundaries for a scoped service, not a guarantee about an existing deployment. Each needs a documented agreement and validation for your configuration.

We would not treat a working demo as evidence that privacy, support access, or recovery arrangements are ready.

No standing Sekora access

The proposed model requires no standing Sekora access to client data or secrets. Your business should control its information and the permissions used to run the workflow.

Support may require an exception. Before deployment, we must agree on an approved, time-limited, audited support process. It must define:

• Who can authorize access and which information the support task requires.
• How access starts, expires, and can be revoked.
• What access and actions are recorded, and who reviews those records.
• How credentials and any diagnostic material are handled afterward.

This process must work in practice before we can promise it as a service feature. Routine maintenance and monitoring also need a defined method without routine access to business content. Any exception must be explicit.

Map the information flow

A proposal should identify where inputs, outputs, logs, saved context, and backups live. It should name any model or service providers receiving information and explain why they receive it.

Retention, provider use of data, deletion limits, and backup handling need review for the actual services selected. Logs can contain sensitive content too.

We must also agree on incident contacts, reporting responsibilities, and what happens if a workflow needs to be paused.

Choose hosting around the task

Local, client-hosted, and approved cloud configurations are choices to evaluate. Availability depends on scoped technical and commercial validation, including model quality, hardware, cost, and support needs.

A locally running model does not establish that information never leaves your network. Connected tools, updates, logs, and other services can create external data flows. We need to check the whole workflow.

Limit permissions and actions

Use only the information and permissions the agreed task needs. Customer credentials and private knowledge must not become part of shared templates or another customer’s setup.

Any deployment needs validated client-specific access boundaries. We do not claim absolute isolation or a complete audit trail without evidence for that configuration.

A workflow that prepares a draft does not need permission to publish it. Sending messages, changing records, or spending money requires explicit boundaries and testing. Consequential actions need human approval.

Keep people responsible for review

Your business selects approved inputs and names the person who checks outputs. That reviewer must check important facts and decide whether the result is suitable for use.

A proposed workflow is not a compliance certification or a substitute for legal, medical, financial, or other professional advice.

Plan the exit before starting

The agreement should cover exports, access removal, account handover, retention, deletion, and remaining backup copies. It should name who performs each step and any provider limits or costs.

Recovery and restoration claims also need testing. They cannot be inferred from having a backup setting enabled.

Website privacy is a separate matter

This page explains proposed service boundaries. The website privacy policy describes website information handling. A service agreement must address the selected workflow separately.

Discuss your requirements in general terms first. Do not submit secrets or private business records through the inquiry form.