I recently came across a small technology project that made me think about one of the less discussed risks of generative AI.
We usually talk about AI in terms of productivity, efficiency, and new opportunities. It allows people to automate routine tasks, process large amounts of information, and build applications with much less effort than before. Many of these opportunities are genuinely useful, and I am certainly in favor of making good use of them.
But there is another side to this development. When technology makes it easier to implement ideas, it also makes it easier to implement poorly considered ones.
In this particular case, someone had taken information shared in a private messaging group and turned it into a structured online directory with the help of AI. The result was technically quite impressive. From a privacy perspective, considerably less so. Anyone familiar with data protection regulations could probably come up with quite a few questions about the arrangement.
What made the case particularly interesting was that the person behind it was someone with strong technical skills. A person who clearly knew how to make technology work.
To me, this is as much a story about expert work as it is about AI and privacy. Technical competence is valuable, but so is the ability to recognize when a technically feasible solution might be a bad idea.
From a Group Chat to a Personal Database
The case involved a private group chat whose members had shared information about themselves and their families. In the following, some details have been generalized to protect the people involved.
As people often do in such groups, they had introduced themselves and mentioned various everyday details, including hobbies, family relationships, and where they lived. The group also contained information normally available through the platform, such as full names and contact information where people had provided them.
One technically capable member of the group decided to make this information more useful. With the help of AI, information from the conversations was extracted and organized into a separate web application. Details scattered across different messages were combined into structured personal profiles. Some additional information was collected from other sources.
The resulting directory brought together names, contact information, family relationships, hobbies, photos, and other personal details. Some of the information concerned children.
It was unclear how the personal information had been processed by the AI service and where the resulting data was stored. At least the application was password-protected.
The people whose information appeared in the directory had not been asked beforehand whether they wanted their information used this way.
I have no reason to believe the person intended anything harmful. Quite the opposite. The project seemed to be an attempt to make everyday life a little easier for the group. And in that sense, it was a fairly typical technology project: someone identified a problem and came up with a technical solution.
But good intentions and technical competence do not automatically make an idea good.
The Same Information, a Different Purpose
One could argue that the information was already available to members of the chat group. So what was the problem?
Quite a lot, actually. There is a difference between sharing something in a conversation and having that information collected, combined with other sources, and stored in a structured database.
In a group chat, information appears in a particular context. Someone mentions their child’s hobby or where the family lives. Another member might remember the information, or perhaps search for it later in the conversation. The information is available, but it is scattered across messages and mixed with ordinary discussion.
A database changes the situation. Information becomes easier to find, combine, analyze, and reuse. Details that seemed harmless individually can form quite a comprehensive picture of a person or family when brought together. The distinction becomes especially important when the information concerns children.
And the fact that someone has voluntarily shared information in one service does not automatically mean they have given consent for it to be processed in another service for a different purpose.
There is also a separate issue with using AI to process the information. If personal data is uploaded to an external AI service, it may be transferred to another service provider, potentially for processing or storage in another country. Depending on the service and its settings, the information may be retained or even used to improve the service.
The platform used to host and publish the resulting application introduces similar considerations. Personal information is now stored and processed in another service, with its own data handling practices, access controls, and potential risks. Password protection may help restrict access, but it does not establish whether collecting and processing the information was appropriate in the first place.
This makes it important to understand what information is being submitted to these services, where it goes, who can access it, and what happens to it afterward. In this particular case, the AI service used, the extent of the information submitted to it, and the location where the application data was stored remained unclear. This made it difficult to assess the actual risks.
There are also legal considerations. The applicable rules depend on the jurisdiction and the circumstances. In Europe, for example, the GDPR may be relevant, although its applicability to activities of a purely personal or household nature has its own limitations. I will not attempt to give a legal verdict on this particular case. The questions about purpose, transparency, necessity, and appropriate handling of personal information are worth asking regardless.
This is a familiar issue in professional data management. Information has a purpose, a context, and an expected audience. Moving it somewhere else can change the risks considerably, even if the underlying facts remain exactly the same.
AI Removes Friction. Sometimes Too Much.
A few years ago, building this kind of directory would have required a reasonable amount of work. Someone would have needed to collect and clean the information, identify the relevant details, combine records, design a database, build an interface, and arrange hosting. For a small volunteer project, that might have been enough effort to discourage the whole idea.
Generative AI changes the equation. Today, you can provide a model with unstructured information and ask it to extract names, identify relationships, organize the data into tables, and help build a working application. You do not necessarily need much programming experience. And if you already understand technology, you can move even faster.
This is one of the great benefits of AI. It allows people to create useful applications and automate work that previously required considerable effort. Small organizations and communities can build solutions that would have been too expensive or time-consuming just a few years ago.
Unfortunately, the same applies to less sensible ideas.
We often talk about reducing friction as if it were always a good thing. In reality, some friction has a useful purpose. It gives us time to reconsider what we are doing, whether it is necessary, and what consequences it might have.
When building something becomes almost effortless, the distance between having an idea and implementing it can become very short. Sometimes the technical solution is ready before anyone has properly considered the problem.
And once something has been built, it becomes tempting to use it. After all, someone has already spent time developing it, and the result might be actually useful and look rather impressive.
When Technical Competence Becomes Part of the Problem
We often associate technology-related risks with inexperienced users who do not understand what they are doing. But experienced professionals can create risks of their own.
They know how to build applications, connect services, automate processes, and overcome technical limitations. When something looks inconvenient, they naturally start thinking about ways to improve it. This is generally a valuable characteristic. Much of technological progress comes from people who see a problem and decide to solve it.
However, the ability to implement a solution does not necessarily come with good judgment about whether the solution is appropriate.
In fact, strong technical skills can sometimes make the situation worse. The person may be so focused on making something work that other considerations receive too little attention. Technical challenges are interesting, and solving them can be quite rewarding. Questions about data protection, responsibilities, or whether people actually want the solution may seem considerably less exciting.
I recognize this tendency in expert work more generally. When we know how to solve a problem, we can become rather enthusiastic about doing so. And perhaps a little impatient with people who raise questions that seem to slow things down.
Privacy, security, legal requirements, organizational responsibilities, and the interests of other people can start looking like obstacles to implementation. But these considerations are part of the problem that needs solving, rather than something to deal with after the technical work is finished.
A senior expert should be able to look beyond the implementation and consider the wider consequences. That includes understanding what information is being processed, who is affected, what obligations are created, and what happens if the solution works exactly as intended. After all, a system can work perfectly well and still be a bad idea.
What Should You Do Instead?
Some organizations respond to the risks of generative AI by restricting or even banning its use altogether. I can understand the reasoning, especially when sensitive information is involved. But I do not think a blanket ban is necessarily the best solution. There are enormous opportunities in using AI to solve everyday problems, and organizations should be able to benefit from them.
What we need is a combination of professional judgment, clear responsibilities, and common rules about how AI can be used. People should understand which tools are appropriate for different purposes, what information they can process, and when additional assessment or approval is needed.
For individual professionals, I would suggest a few fairly straightforward practices before starting an AI-assisted project involving other people’s information.
Start with the purpose, not the technology. What problem are you actually solving, and who benefits? Sometimes a simple shared document or an existing application is sufficient. Everything does not need to become a new web service.
Consider whose information you are using. Think about what people originally shared, why they shared it, and whether they would reasonably expect the proposed use. If you are creating a directory for a group, involve the people concerned in deciding what information should be included.
Minimize the data. Collect only what is genuinely needed. Avoid combining information from additional sources merely because you can. Be especially careful when children’s information is involved.
Understand where your data goes. Before uploading personal or confidential information to an AI service, check how the service processes and retains it. Consider where the resulting application’s data will be stored and who will have access to it. Use appropriate services and configurations, and consider whether you can work with synthetic or properly anonymized example data instead.
Use AI to challenge your idea. This is perhaps the most ironic recommendation. Before giving an AI tool the real information, describe your proposed solution without including personal data. Ask it to identify privacy and security risks, questionable assumptions, and alternatives that require less information.
AI is not a lawyer, and its answers certainly should not be accepted without criticism. But letting it spend five minutes finding problems with your brilliant idea might be surprisingly useful. It can help you identify questions that deserve further consideration before you start building anything.
Sometimes AI is at its best when it helps you decide what not to build.
The Ability to Build Is Becoming Cheaper. Judgment Is Not.
Generative AI is changing the economics of software development and information processing. Tasks that once required considerable technical expertise can now be completed by people with relatively little experience. And skilled professionals can build solutions much faster than before.
That is largely a positive development. But as the ability to create technology becomes more widely available, the importance of deciding what deserves to be created increases.
The case I described was not particularly interesting because someone had made a technically poor application. The technology apparently did what it was supposed to do. The more interesting question was whether anyone had properly considered what it should do in the first place.
We will probably see many more enthusiastic AI experimenters building solutions for their workplaces, communities, and everyday lives. Some will be genuinely useful. Others will create unnecessary problems involving privacy, security, or the interests of the people concerned.
And this is hardly a problem limited to amateur developers. Experienced technology professionals, consultants, and architects should be particularly well equipped to recognize when a technically feasible solution is also sensible. That is part of what their experience should bring to the table.
The tools are becoming remarkably capable. Our judgment needs to keep up. Just because AI makes something easy to build does not mean it is worth building.
🤖 What Are Enterprise Architects Doing With AI?
Enterprise architects seem to have found a new hobby: building their own architecture tools through vibe coding. I have experimented with it myself, and I am seeing more architects developing their own modeling applications, visualizations, and even enterprise architecture repositories.
But are these tools actually useful, or are we just creating more software to maintain?
In my latest article on Enterprise Architecture Transformation, I explore the opportunities, risks, and practical considerations of architect-made tools.
👉 Read: The Rise of Architect-Made Enterprise Architecture Tools Through Vibe Coding
📚 Related Reads from Expert Work by Design
If you found this useful, you might also enjoy the following articles:
👨💻About the Author
Eetu Niemi is an enterprise architect, consultant, and author.
Follow him elsewhere: Homepage | LinkedIn | Substack (enterprise architecture ) | Medium (writing) | Homepage (FI)
Books: Enterprise Architecture | The Senior Expert Career Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time
Web resources: Enterprise Architecture Info Package (FI)





