AURAS INNOVATION · PRIVOID.AI

Responsible AI and Acceptable Use

Effective 30 September 2026 · Version 2

Privoid.ai describes possible custom AI and machine-learning projects. This page sets boundaries for website inquiries and explains the risk questions a real project must answer. It is not a certification that any example on this site is safe or approved for production.

1. Uses we will not authorise through this site

Do not use this website to request or facilitate unlawful surveillance, discrimination, fraud, malware, deceptive impersonation, exploitation of children, evasion of safety controls, or violations of privacy and intellectual-property rights. We may decline inquiries involving these purposes.

We do not offer a website-based approval for automated decisions in hiring, credit, insurance, healthcare, law enforcement, education, public benefits, or other contexts with significant effects on people. We also do not present reference prototypes as controls for industrial machinery, critical infrastructure, emergency response, weapons, or physical safety. Such work, if considered at all, requires separate legal, safety, technical and domain review and an express written agreement.

2. Questions before a client deployment

For each proposed use, the contracting parties must identify the intended purpose, affected people, data sources and permissions, prohibited uses, where data and model outputs flow, the model and third-party dependencies, foreseeable misuse, and who can stop or override the system. A risk assessment should match the actual impact of error, bias, privacy loss, security failure, and model drift. This assessment is project-specific; a generic website statement cannot replace it.

3. Testing and evidence

Benchmarks must define the dataset, ground truth, sampling, time period, hardware, baselines, evaluation metrics, confidence limits where useful, and failure cases. Training and test data must be separated appropriately. A model that performs well on a reference sample may fail on a new domain, changed population, rare event, adversarial input, or production integration. The project acceptance plan must state what constitutes a pass and what happens when the system does not pass.

Outputs that are predictions, classifications, or generated text should be presented as such, with uncertainty and limitations where relevant. We will not describe a modeled saving as a measured customer result or a prototype score as regulatory approval. See AI and Results Disclosures for the evidence status of this site's examples.

4. Human control and ongoing operation

A production design should specify when a person reviews an output, how a user contests or corrects an error, how unsafe outputs are escalated, who can disable the system, and which party monitors performance and incidents after handover. These are not automatic features of every model. Their implementation, service levels, audit logs, and ownership must be defined in the signed statement of work and operational plan.

5. Customer and vendor responsibilities

The customer must have rights to provide its data, choose a lawful purpose, inform affected people where required, and provide domain experts for acceptance testing. We must disclose the architecture, relevant third-party dependencies, and known limitations for work we agree to deliver. Each party's data-protection role, security controls, support duties, and incident notices must be written into the project documents. Neither party should assume that an “on-premises” option automatically removes all privacy, security, safety, or licensing obligations.

6. Changes

We may update this public intake policy as technology and law change. A signed client agreement governs its own project and cannot be amended by changing this page. Questions or misuse reports may be sent to support@privoid.ai.