Trust Center
AI-assisted development
Last reviewed: 2026-08-20
This page answers a question that increasingly appears in security questionnaires and vendor due diligence: is your software written with AI, and what stops that becoming a defect in our compliance records?
It is a different question from AI handling, which covers how AI is used inside the product to process your data. This page is about how the product itself is built.
The short answer
Yes. Compliance Care uses AI-assisted development. A substantial proportion of the code in the Larenta platform is drafted with the assistance of large language models — currently Anthropic's Claude — working to instructions from our principal.
We state that plainly rather than leaving it to be inferred. What matters is not who drafted a line, but what every line has to survive before it runs against your records.
What every change must pass
Six checks run on every change, and all six block a merge:
| Check | What it enforces |
|---|---|
| Type checking and linting | The whole codebase compiles and passes lint |
| Unit tests | The full suite — 2,642 tests as at 20 August 2026 |
| Row-level-security gate | A real Postgres is started, every migration applied, and the tenant-isolation suite run against it. The boundary that separates one provider's records from another's is tested against the database, not a mock |
| Dependency scan | A high or critical advisory in a production dependency blocks the build |
| Static analysis | Semgrep, including four rules written specifically for this codebase's security model |
| Hygiene | Including the forbidden-phrasing scan that protects our impartiality position |
The four bespoke static-analysis rules are the ones that most directly answer the question on this page. They catch a route added without an authorisation check, use of the privileged database client that bypasses tenant isolation, unsafe HTML rendering, and privileged credentials reachable from browser code. Those are precisely the mistakes an automated drafting tool is most likely to make — so they are machine-checked on every change rather than left to a reviewer's attention.
What we do not claim
Consistent with the rest of this Trust Center: where the honest answer is "not yet", we say so.
- There is no peer review. The company has two directors, but only one is operationally active — the second holds no operational role and has no system or customer-data access. Our principal is therefore the sole human reviewer of every change, and there is no separation between the person who writes a change and the person who approves it. The automated gates above are the compensating control, and we do not present them as equivalent to independent review.
- We have not had an independent penetration test. See Penetration testing.
- We are not ISO 27001 certified. See ISO 27001 posture.
Additional rules for AI-assisted work
- No customer data ever enters a development session. Source code, schema, and synthetic fixtures only. Participant records, worker records, and customer documents are never used as coding context.
- No credentials in a development session. Keys and connection strings are referenced by name, never by value.
- Security-relevant changes are read line by line by the principal before merge — authentication, tenant-isolation policies, privileged database access, API request verification, and billing.
- Database migrations are never accepted on assurance. Every one runs against a real Postgres before it can merge.
Where this leaves your contract
Our warranty to you is unchanged by how the code was drafted: we perform the Service with the degree of skill and care reasonably expected of a competent provider (Terms of Service §14.1). Authorship is not a defence and we do not offer it as one.
The full internal control document, including our ISO/IEC 27001:2022 Annex A mapping, is CC-SEC-SDL-001. It is available to customers and prospects on request.
Contact
Questions about this page: info@compliancecare.com.au.