//Data handling

The initial workflow audit should describe the process, tools, bottlenecks, and desired outcome. Do not send production credentials, private datasets, or sensitive documents through Calendar, WhatsApp, or ordinary email.

The call works best with a description, not data. Useful things to bring:

• the steps of the workflow as your team would explain them
• the names of the tools involved, and who owns each
• one or two example cases with names, numbers and personal details removed
• screenshots of the screens involved, with private fields blurred

Required systems, data categories, permissions, third-party services, model providers, retention needs, and approval points are documented in the project scope before access is requested.

Where the selected tools support it, the delivery approach uses client-controlled accounts and the narrowest practical permissions. Exact controls depend on the tools and written project agreement.

• Access is granted through each tool's own user or API-key management, not by sharing your personal login.
• Where a tool supports it, we use a dedicated account or key for the workflow, so its actions are visible and can be revoked on their own.
• Credentials are exchanged through the tool or a secure channel agreed in the scope, never in chat or ordinary email.

Which AI model provider a system uses, how that provider treats the data sent to it (including whether it may be used for training), and any regional options the provider offers are chosen per project and written into the scope before production data is connected. We do not make a single promise here because it genuinely depends on the provider and plan selected.

Systems are first built and tested on sample or redacted cases. Production data is connected only after the workflow owner has reviewed the behaviour on those cases and agreed to proceed.

Workflows are designed around explicit actions and ownership. High-impact writes or external communications can be placed behind human approval gates when included in scope.

Logging, fallback behavior, and recovery steps are defined for the implemented workflow rather than assumed from a generic policy.

The agreed handoff identifies configuration, ownership boundaries, operating instructions, and next steps. Access that is no longer required should be revoked at handoff or project end, and the handoff lists each account and key so your team can confirm it.

Hosting location, subprocessors, model data use, retention, deletion, incident response, backups, and intellectual-property terms vary by architecture. They must be stated in the written proposal or service agreement; this page does not claim certifications or controls that have not been contractually established.

Contact neurosformer@gmail.com before sharing sensitive information or to request deletion of project data that Neurosformer is not required to retain.