Why Security is the DNA
of the Entire eety.ai Application.

There is a version of security that is a checkbox. And then there is ours.

I have seen how most software products approach security. They build the product. They launch the product. And then at some point — usually when a customer asks a difficult question, or when the compliance team gets involved — they go back and 'add security'. A checkbox on the marketing page. An SSL badge in the footer. A privacy policy written by a lawyer who had not read the codebase.

That is not an unfair thing to do. That is, honestly, how most SaaS tools are built. Ship fast; harden later.

I could not do that with eety.ai. Not because I am particularly principled about software methodology — but because the moment I thought clearly about what this product handles, I realised there was simply no responsible way to do it in that order.

eety.ai processes invention disclosures. These are, by definition, the most commercially sensitive documents your clients will ever produce. Before a patent is filed — before any public record exists — that disclosure is the only thing standing between your client's idea and the rest of the world. Breaching it doesn't just embarrass a firm. It can destroy a patent, obliterate a business, and land an attorney in front of a bar committee.

So when I sat down to design eety.ai, the question was not "how do we add security?" It was: "what kind of system is even acceptable to build here?"

The architectural choices that most users never see

Security decisions that are made during architecture — not after — are invisible when they work. You never see them. You just notice, over time, that nothing has gone wrong.

Here are the ones we made, and why each one matters.

Why "we don't train on your data" is not enough

I keep coming back to this, because I think it is the most important thing for attorneys to understand when evaluating any AI tool for legal work.

Most AI privacy pages say something technically accurate but structurally weak: "We don't use your data to train our models by default." When I read that sentence carefully, here is what I notice: "by default" is not "never". Default settings change. Enterprise tiers may differ from what you signed up for. And "we don't" is a statement of current intent, not a legal commitment. The day they change their mind, they update the policy, send an email that goes unread, and consider the matter settled.

What creates a real obligation is a contract. A DPA. A bilateral legal instrument with defined obligations, audit rights, and — crucially — liability provisions if those obligations are breached.

eety.ai is covered by the latter. And because I operate as a developer on enterprise API tiers — not the consumer-grade tiers that most free tools use — the contractual baseline is fundamentally different.

The part that was actually hard to build

The encryption, the DPAs, the isolated storage buckets — those are table stakes. They are important, but they are also straightforward: you make the right vendor choices, you configure things correctly, you sign the right agreements.

The genuinely difficult part was the two-phase architecture. During the understanding phase, yes. The extracted text of your disclosure goes to Gemini. That is the price of actually comprehending the invention. What I was not willing to accept was continuing to re-send that raw disclosure context for every subsequent operation: every drafted claim, every section of the description, every revision.

Building the Brain (the 15-point extraction engine that produces a structured, scoped invention model) meant that every drafting call that follows works from that model, not from your original document. Your file is read exactly once for understanding. After that, it stays in our encrypted storage and does not travel anywhere. This required significantly more engineering than the alternative. The alternative was: pipe the full disclosure into every prompt, forever. A lot of AI patent tools do exactly that.

That was not a trade-off I was willing to make.

Security as product design, not product policy

Here is the thing I want attorneys to take away from this. When security is designed in from the start — not added as a feature — it stops being a claim you have to evaluate on trust. It becomes something you can reason about structurally.

You can ask: "Even if something went wrong in your system, what is the worst that could happen?" And if the architecture is right, the answer is constrained in a way that a policy statement could never constrain it. A bug in our interface cannot hand one firm's trade secrets to another firm's session. The database query itself would return nothing. That is not a promise we are making. It is a consequence of how the system was built.

I also want to be transparent about what we are not claiming. Your disclosure is read by Gemini during the Brain extraction phase. That is how the understanding is built. What we control is: what happens to it after that, who it sits next to, whether it gets re-sent unnecessarily, and crucially, whether the AI provider is bound by a contract that prohibits using it for training. The answer to the last one is yes, under our enterprise DPA. Not a settings toggle. A legal commitment.

I built eety.ai because I wanted to use it myself. And I could not use a tool for this kind of work unless I could clearly reason about what happened to my client's data, at every step, in every failure mode, under every edge case I could think of. That meant being honest about what the system actually does, not just what sounds reassuring.

As it turns out, most attorneys feel the same way. The question comes up in every single demo :)