Effective
AI Usage Policy
- Effective date
- Last updated
1. Purpose and scope
This policy defines permitted AI-assisted use of Conflux and the conditions that must be met before an AI capability is enabled. It applies to participating organizations, their authorized users, and people configuring or operating Conflux workflows. Each use must also comply with the applicable service agreement, Privacy Policy, and approved tenant or pilot scope.
Conflux is being introduced through controlled pilots. A capability described in this policy is a requirement for its approved use, not a statement that the capability is already available. Tenant AI inventories, broader AI execution, Workflow Studio, and business integrations remain planned product phases. Access to the portal does not itself authorize AI processing, workstation collection, an external integration, or a production action.
3. Human review and decisions
AI output may be incorrect, incomplete, biased, outdated, or misleading. An authorized reviewer must verify material facts, calculations, source support, rights to use content, and business suitability before relying on output or sharing it externally. AI output is not proof that an action succeeded.
AI must not approve its own access, policy exceptions, production release, or expansion of scope. Consequential actions require the applicable human approval and separation of duties. A changed process draft or execution scope must be reviewed again where the prior approval no longer covers it.
4. Uses outside the controlled pilot
The controlled pilot does not permit autonomous decisions determining a person's employment, credit, housing, insurance, education, medical treatment, or legal eligibility. It does not permit safety-critical control or representation of AI output as professional medical, legal, or financial advice. Any proposed expansion requires a separate assessment, explicit authorization, and verified controls before use.
Users must not use Conflux for unlawful discrimination, fraud, deceptive impersonation, exploitation, unauthorized surveillance, unauthorized access, or harmful interference with systems. They must not bypass tenant boundaries, approval gates, audit records, collection limits, or stop controls. They must not submit content they lack authority to process or use AI to conceal the origin of evidence or fabricate approvals.
5. Data minimization and process observation
Only data necessary for the approved purpose may be processed. Synthetic or minimized data must be used when it can satisfy that purpose. Credentials, private keys, authentication challenges, and recovery secrets must not be entered into prompts or ordinary evidence records. Sensitive personal, regulated, or confidential data requires an explicitly approved handling boundary before use.
The presently demonstrated Edge process-capture boundary is a separately authorized, metadata-only application observation. It excludes screenshots, window titles, page content, URLs, browser history, keystrokes, clipboard contents, and raw workstation evidence uploads. Recording requires the approved node, source, authority, time window, and budgets. Only a human-reviewed and approved minimized process map may be promoted through that workflow. This demonstration does not authorize collection from a real customer.
6. Model selection and external processing
When AI execution is introduced, Conflux must evaluate permitted execution in a fixed order: deterministic processing, then an eligible local model, then an explicitly approved external model. Eligibility must be decided before execution using task capability, data restrictions, quality requirements, and approved budgets. A timeout is a failure to handle; it is not permission to send data to another provider.
External model processing requires approval of the provider, intended use, data categories, destination, and relevant retention and training terms. Only the minimum approved context may leave the approved boundary. Local processing must also remain within its approved access and storage boundary. Changing a provider or model must not silently broaden data access or permitted actions.
7. Training, memory, and learning
Tigunny will not use customer data to train foundation models. External providers may receive customer data only under an approved configuration and terms consistent with that restriction. This policy does not represent that every provider offers identical retention or training settings.
Retaining prompts, retrieval indexes, embeddings, reusable memory, or evaluation examples requires an approved purpose, tenant boundary, and retention rule. Such retention is not implicitly authorized by permission to perform one task. Operational learning may propose improvements; it must not autonomously change policy, permissions, routing rules, limits, or an approved process version.
8. Automation and integrations
Permission to draft a suggestion does not grant permission to execute it. Before an automated action is enabled, its approved scope must identify the systems, credentials, allowed actions, destinations, time window, and limits. Credentials must be held by the approved server-side mechanism and limited to the required permissions.
Execution must have applicable validation, bounded retries and resource use, duplicate-effect protection, monitoring, evidence of results, and a tested stop and recovery path. An ambiguous provider response must be reconciled before retrying an action that could create another external effect. Unavailable approvals or controls require the action to stop.
9. Evidence, retention, and incidents
Evidence should record the minimum identifiers, versions, approvals, hashes, outcomes, and operational facts needed for review. It must not accumulate excluded content for convenience. Retention periods, access, deletion procedures, and any applicable legal hold must be agreed for the specific service or pilot before customer processing begins. This policy makes no universal immediate-deletion or zero-retention promise.
Users must stop affected work and report suspected unauthorized processing, incorrect consequential output, exposed credentials, or control failures to the designated pilot contact. Tigunny may suspend affected capabilities while scope, access, or safety concerns are investigated. Re-enablement requires the appropriate review and authorization.
10. Transparency, changes, and contact
Participants must be told when AI materially contributes to a deliverable or decision where that fact affects their ability to assess it. Human review does not eliminate model limitations. No policy statement constitutes a certification or guarantee of error-free operation.
Material changes to this policy must be versioned and reviewed before they govern new processing. Changes that expand an existing pilot's scope require the corresponding updated authorization. Questions or concerns may be directed to info@tigunny.com; active pilots must additionally name an operational escalation contact.