Where We've Been, Part Two: The Work You Don't See

In the last post, we talked about the testing behind 1two.one, the scenarios, the comparisons, the process of finding out what the system was getting right and where it needed to improve.

Testing is only one side of getting this right. Alongside it, we've been doing something quieter and, in some ways, more fundamental.

Security. Data protection. The unglamorous, essential work of making sure 1two.one deserves the trust it's asking for.

We wrote before about managers across social care already recording meetings all over the place — Teams, Word, consumer apps, whatever's to hand. The adoption is happening. The governance, for many, still has room for improvement. That gap is exactly what we've spent the last few weeks closing, in our own product, properly.

Data residency, London and Dublin, no exceptions

When we say your data stays in the UK/EU, we mean it without caveat. Every piece of a supervision session, the audio while it exists, the transcript, the structured record, and every step of AI processing in between, is handled entirely within UK and EU infrastructure. Nothing crosses that boundary.

Getting here took real work. Earlier in development, part of our AI processing used a US-based provider, which meant relying on Standard Contractual Clauses, the lawful mechanism UK GDPR provides for that kind of transfer. It was compliant, but we weren't satisfied with "compliant." Over the past few weeks, following an extensive testing programme comparing providers on accuracy, nuance, and quality, we moved our core AI processing to infrastructure that runs entirely in UK and EU regions. The switch wasn't just a residency win, it also produced a genuinely better product, with more accurate, more nuanced evidence capture than what came before.

No model training. Full stop.

This is one of the clearest lines we draw and one of the most important. Nothing processed through 1two.one is ever used to train an AI model, ours or anyone else's. Not the transcript, not the audio, not the structured output. This was true before the infrastructure move to UK and EU processing, and it remains true now.

This is the single biggest difference between using 1two.one and pasting a supervision transcript into a consumer AI tool. Free tools are free for a reason, and that reason is usually your data. A supervision conversation contains a staff member's performance concerns, wellbeing disclosures, sometimes health information. None of that should ever become training data for a model that has nothing to do with the conversation it came from.

Encryption, properly implemented

Data is encrypted both at rest and in transit, using industry-standard AES-256 encryption. That's not unusual for a well-built platform. What matters more is how consistently and completely it's applied, and we've spent real time over the past few weeks auditing every point where data moves or sits to make sure there are no gaps.

Row-level security

Every organisation's data is completely isolated from every other organisation's data, enforced at the database level, not just through application logic that a bug could bypass. If you're a provider using 1two.one, your supervision records are architecturally incapable of being seen by another organisation, regardless of what happens elsewhere in the system.

This is the kind of thing that's invisible when it works and catastrophic when it doesn't. We've spent a significant chunk of the last few weeks stress-testing it.

Multi-factor authentication

Access to the platform requires more than a password. This sounds basic, and it is, but basic security fundamentals done properly are worth more than clever features layered on top of weak foundations.

A completed DPIA

We've carried out a full Data Protection Impact Assessment, the formal process UK GDPR expects for any processing that's likely to result in high risk to individuals, which supervision data absolutely is. Not because a template said we should, but because the exercise itself forces you to think properly about every point where things could go wrong and design against it before it happens.

Why this is the post, not a feature list

None of this is a feature you'll click on. None of it shows up in a demo. It's the invisible foundation that determines whether everything else we've built, the preparation, the transcription, the regulator-aligned evidence mapping, is something you can actually trust with real data about real people.

The sector is moving toward AI-assisted supervision whether any individual provider decides to or not. Managers are already recording sessions with whatever tool is closest to hand. The question was never going to be whether this happens. It was always going to be whether it happens safely.

We think the answer to that question is decided in exactly the kind of work we've spent the last few weeks on. Not the visible features. The quiet architecture underneath them.

There's a lot more to share, including some of what's coming for the Care Show in October. But we wanted testing and security to be the two posts that came first, because trust has to be earned before anything else we say matters.