In the year 1851, a man named Joseph Paxton stood before a group of worried men in London. He was there to talk about the Crystal Palace, a massive hall of glass and iron. It was a new kind of building, and to many eyes, it looked thin and weak.

The men in charge of the Great Exhibition wanted proof that the floor would not collapse under the weight of thousands of visitors. Paxton did not give them a thick book of rules or a signed letter from his father. Instead, he made a troop of soldiers march in step across the iron beams. He made them jump. He made them run. The building stayed still.

Today, we have lost the habit of the march. We have replaced the weight of the soldiers with the weight of the word. When a big company wants to buy software, they do not jump on the floor. They send a spreadsheet.

Marcus is thirty-four years old and works in a room with no windows. He is not a coder. He does not know how a database talks to a web browser. But because he is the most careful person in his office, he has been told that security is now his job.

It is a Thursday afternoon, and Marcus is tired. He has spent the last three hours looking at a forty-question assessment sent back by a new vendor. He is at Question 29: “Does the vendor maintain a documented data retention policy?”

The vendor has typed “Yes.” They have attached a PDF. Marcus clicks the link, sees that the file has fourteen pages of small print, and closes it. He does not read it. He does not need to read it to do his job. His job is to see if the box can be ticked.

If the box is ticked, the risk is gone-not the risk of a data leak, but the risk of Marcus being blamed if something goes wrong. He ticks the box. He feels a small sense of win, even though he has learned nothing about where his company’s data will actually go.

I just had to force-quit my email app seventeen times because a “security update” froze my screen. It is a sharp reminder that the things we do for safety often have nothing to do with how well a tool works. We have built a world where the appearance of safety is worth more than the fact of it.

The Hidden Law of the Questionnaire

This is the hidden law of the questionnaire. Whenever a check becomes a standard, it stops measuring how a system works and starts measuring how well a company can fill out a form. A vendor with a bad system but a great writer will beat a vendor with a great system but a bad writer every time.

The writer knows the magic words. They know that “industry standard” means “we do what everyone else does, even if it is not enough.” They know that “encryption at rest” sounds safe, even if the vendor keeps the keys under the front mat.

We call this a ritual because that is what it is. It is a dance we do to appease the gods of liability. Both sides know the dance. The buyer sends the form because they must. The seller fills it out because they want the check. Neither side wants to break the spell.

If the buyer asks a hard question that is not on the form, the deal slows down. If the seller tells the truth about a weak spot, the deal dies. So everyone stays on the path.

“A smoke detector on a wall with no battery is just a plastic puck.”

– Ruby B., Building Code Inspector

Ruby B. is a building code inspector I know who has spent thirty years looking at the bones of houses. She once told me that most security questionnaires are full of plastic pucks. They ask if you have a fire plan, but they never ask if you have any wood in the house.

The problem gets worse when we talk about new things like AI. A lawyer or a doctor might want to use a bot to summarize a long file. They know they should be careful. They ask the IT team if the bot is safe. The IT team sends the questionnaire.

The AI company says they have a SOC2 audit. They say they have a “privacy policy.” They say they care about your data. But a policy is just a list of things a company says it will do. It is a promise.

In the world of data, no amount of paperwork can change the math of a bad architecture. If a person can see your data, they can steal it. If a server stores your data, a hacker can find it.

If you want to know if a house is strong, you do not ask for a letter from the guy who sold the wood. You look at the joints. You look at the foundation. In the world of software, the foundation is the architecture. It is how the data flows from one point to another.

For professionals who handle secrets-lawyers, doctors, or bank staff-the standard way of using AI is a trap. Most tools take your words, send them to a big server, and keep them there. They might say they do not use them to “train the model,” but the words are still there.

They sit in a database. They are a target. If you send a questionnaire to these companies, they will give you a “Yes” for every box. They have the documents. They have the writers.

Paxton’s Soldiers in the Digital Age

This is why some people are looking for a different way. They want proof that is more like Paxton’s soldiers and less like Marcus’s spreadsheet. They want a system where the vendor cannot see the data even if they wanted to.

This is what we call architectural security. It is not a rule in a handbook; it is a fact of the build.

When you use a tool like

Tunneltunnel,

the protection is not based on a promise. It is based on the way the software is made.

The words you type are turned into noise on your own desk before they ever touch a wire. The company does not have the key to turn that noise back into words. They do not store your name. They do not keep a log of your thoughts.

If a government or a thief showed up at their door with a box of legal papers, the company would have nothing to give them. That is the difference between a policy and a mechanism.

One of these makes for a very long and boring PDF. The other makes for a safe night of sleep. But in the current world of buying and selling, the boring PDF is often what wins the deal. We have become so used to the ritual that we forget why we started doing it.

The cost of this shift is high. It creates a false sense of peace. A company thinks they are safe because they have a folder full of signed forms. Then a leak happens. They find out that the “data retention policy” they ticked off on page 29 had a hole in it big enough to drive a truck through.

They find out that the “encryption” they were promised was only active when the data was sitting still, not when it was being used.

The only way to break the cycle is to ask the one unscripted question. Do not ask “Do you have a policy?” Ask “If your lead engineer went rogue tomorrow, could he read my client’s files?”

If the answer is “Our policy forbids that,” you are looking at a plastic puck. If the answer is “No, because the keys never leave the user’s device,” you are looking at iron.

We are entering a time when the amount of data we create is growing faster than our ability to guard it. If we keep relying on the ritual of the form, we will keep failing. We need to stop being like Marcus, ticking boxes on a Thursday afternoon, and start being more like Paxton, making the soldiers jump.

The ink on a signed contract cannot stop a leak once the pipe has already burst.

The next time you are asked to vet a tool, or the next time you are looking for a way to use AI in your firm, look past the certificates. Look at the flow of the data. If the vendor says they have everything under control, ask them to show you the joints.

Ask them why you should trust their heart when you could trust their code instead. The questionnaire is a map that does not care if the road has been washed away by the rain. To stay dry, you have to look at the road yourself.

We often think that more paperwork equals more safety. But in truth, the more paperwork there is, the less likely it is that anyone knows what is actually happening.

When we finally learn to value the architecture over the assertion, we will find that we do not need forty questions to feel safe. We only need one.