Intelliots — Building Beyond.

/ Compliance

Privacy is a foundational architecture decision, not a checkbox.

Privacy by design is applied from the first sprint, because retrofitting it is expensive and rarely convincing to a regulator. For platforms serving minors, we apply a stricter standard again.

/ Architectural enforcement

Enforced by the architecture, not by policy.

A policy states an intention. An architecture removes the option. Where a control matters, we prefer the second.

Data boundary between your infrastructure and an external model provider Identifying records sit in a primary store inside your infrastructure. They pass through an abstraction layer that strips identifiers, then a backend proxy, and only an anonymised context object crosses the boundary to the external model provider. A direct path from the primary store to the provider does not exist. YOUR INFRASTRUCTURE Primary store identifying data RECORD Abstraction identifiers stripped ABSTRACT Proxy server-side ANONYMISED EXTERNAL Model provider third party NO DIRECT PATH — ENFORCED IN ARCHITECTURE
Fig. 03 — Only an anonymised context object crosses the boundary

/01

Identifying data abstraction

Identifying records stay in the primary database. Before any external model call, the profile is converted into an anonymised, structured context object — so raw personal data has no path to a third-party provider.

/02

Server-side model access

Prompts are constructed server-side behind a backend proxy. Client applications hold no provider keys and have no direct network path to a model provider.

/03

Access scoping at the API layer

Role-based access is enforced in the API, not only in the interface. What a role cannot see, it cannot request.

/04

Immutable audit logging

Access and mutation events are logged with timestamp, actor role, and action type, and retained on a defined schedule.

/05

Export and erasure in core scope

Data export and hard deletion are built during the main build, not deferred. Retention and purge schedules are defined before launch.

/06

Documented processor inventory

Every third-party service is documented alongside exactly what data it receives — which becomes your evidence package when a partner or regulator asks.

/ Frameworks

Regimes we design against.

We are engineers, not your legal counsel — these are the frameworks we architect to and document for, so your counsel can review a system that was built with their requirements already in mind.

COPPA

Children's Online Privacy Protection Act (United States)

  • Verifiable parental consent before a child account is activated
  • No behavioural advertising to children
  • Data minimisation — only what the stated purpose requires
  • Right to deletion, without exception

PIPEDA

Personal Information Protection and Electronic Documents Act (Canada)

  • Consent required before collection
  • Individuals can access and correct their data
  • Breach notification obligations supported by logging
  • Accountability principle — a named owner

Law 25

Quebec privacy legislation (Bill 64)

  • Privacy impact assessments treated as mandatory
  • Data localisation controls
  • Right to erasure and data portability
  • The strictest provincial standard in Canada

Student privacy

State-level education data protection (United States)

  • No third-party sharing for non-educational purposes
  • No sale of student data, no behavioural targeting
  • Data processing agreements for every vendor in the chain
  • Evidence package prepared for school partners

Health data

Clinical and patient-facing systems

  • Aligned to HIPAA expectations for handling and access
  • Federated and on-device approaches for sensitive records
  • Clinician review preserved in the decision path
  • Audit trail by default

Explainability

Accountability for automated decisions

  • Confidence scoring on model outputs
  • Attribution methods for individual decisions
  • Human review before high-stakes execution
  • Decision records retained for audit

/ Children's data

A stricter standard for platforms serving minors.

Several of our production systems serve children, including children with learning differences. That work sets the standard we apply everywhere else.

Parental consent architecture

The family account is created first. A child account activates only after verifiable parental consent, and remains linked rather than standalone.

No profiling of minors

No behavioural advertising, no profile building for commercial purposes, and no data shared onward to advertising networks.

Anonymisation by default

Identifying data is abstracted before it reaches any external system, including model providers.

Mediated parental access

Parents receive synthesised summaries and observations rather than raw responses, enforced at the API layer.

Right to erasure

Full export and hard deletion available on request, with aggregate telemetry retained only without identifiers.

Age-appropriate design

Interface, language, and session length designed for the age of the user, with accessibility treated as a constraint rather than a later pass.

Bring us your compliance constraints early.

Start a conversation