On Tuesday I wrote about the court order against Meta in New Mexico, which followed a jury finding that the company misled users about how their information was handled. Meta says it will appeal. The gap between what people are told and what actually happens is the gap I’m asking about this week. Here is Tuesday’s post.
I’m building a product that will hold other people’s business records. I’m not a security expert. This week’s question is one I didn’t know I needed to ask:
How do I know what my app is actually doing with people’s information?
Here’s what I mean. It’s easy to tell an AI what to build. It’s a different habit to ask it what it actually did. Say you ask it to add a feature and it works on screen. Did it change who can see what? Did something quietly stop working, or start going somewhere it shouldn’t? Nobody answers those questions unless you ask them.
Here’s the moment it clicked for me. You can build a slick product in a weekend. But behind it can be a giant, unreadable block of code, and you may not even know what it says. An engineer should be able to look at it and see what each part does with the data. And you should understand the back side well enough to know what it is doing, and what it isn’t doing. Building fast is fine. It just shouldn’t stop you from asking.
Three questions to ask about your own build:
- Could someone other than you open it and explain what each part does with the data? If the answer is “only the AI that wrote it,” that’s worth knowing.
- After a big change, what tells you nothing broke or leaked? “It still looks right” isn’t an answer.
- Who reads that check, and how often? A report nobody opens protects nobody.
Tomorrow I’ll share the check I run on my own build, and what it can’t tell me.
This is general information, not legal advice.
Leave a Reply