Trust starts with precise scope, explicit limits, and honest proof.

Delivery principles

Reliable process matters more than confident language.

• Fixed scope before build starts: Each engagement starts with a bounded workflow definition, acceptance shape, and handover expectation. Work does not begin as an open-ended advisory retainer.
• Manual review stays in the loop: Qualified leads still go through owner review. The intake flow structures the decision, but it does not replace human judgement for edge cases or escalation.
• Handover is part of the job: The default commercial model is build-and-handover with a limited post-handover questions window, not an implied managed service outcome.

Proof limits

Claims stay narrower than the marketing language most buyers are used to.

• No blanket AI Act claim: The site must not claim that the service is 'AI Act compliant' as a general marketing statement.
• Proof stays honest: Compliance language should be explicit about boundaries, documentation posture, and the limits of what is being promised in v1.
• No outcome guarantees: The service can define a workflow, build the agreed system, and hand it over cleanly. It does not guarantee revenue, staffing, moderation, or regulatory outcomes.

Compliance posture

Transparency notes are visible. Overclaiming is not.

• AI-use disclosure: Relevant pages should state clearly when the delivery involves AI-assisted workflow components rather than implying invisible automation.
• Article 50 tracking note: Copy should state that Article 50 transparency and technical-marking requirements are tracked and updated without claiming blanket compliance ahead of the final implementation details.
• EU-conscious hosting and privacy posture: The public site, intake flow, and deployment posture should describe EU-conscious handling, limited data capture, and the owner-locked Cloudflare delivery stack.
• Manual review before automation creep: Structured submissions are reviewed by the owner, and routing remains deterministic rather than open-ended automated decisioning.

This is a copy-and-process posture for v1, not a blanket certification statement.

Decline boundaries

Some requests should stop before proposal work starts.

• Hiring: Requests involving hiring or candidate decision workflows are declined.
• Credit or scoring: Requests involving credit, scoring, or trade-credit decisioning are declined.
• Employment decision influence: Decline outputs influencing employment, performance, retention, or compensation decisions about workers, contractors, or candidates.
• Access or refund gating: Decline outputs gating user access, refunds, or account status without a human reviewer.
• Credit or payment-term classification: Decline outputs classifying customers, leads, or counterparties for credit, payment terms, or trade-credit.
• DSA-platform moderation pipelines: Decline moderation or labeling pipelines for end-user content where the client is a DSA platform.

Scope routing remains deterministic so unsupported work is declined or escalated early.