𝐖𝐡𝐞𝐧 𝐀𝐈 𝐌𝐞𝐞𝐭𝐬 𝐑𝐞𝐚𝐥 𝐏𝐞𝐨𝐩𝐥𝐞. 𝐖𝐡𝐚𝐭 𝐖𝐞 𝐋𝐞𝐚𝐫𝐧𝐞𝐝 𝐖𝐡𝐞𝐧 𝐖𝐞 𝐏𝐮𝐭 𝐈𝐭 𝐢𝐧 𝐓𝐡𝐞𝐢𝐫 𝐇𝐚𝐧𝐝𝐬

AI usually looks impressive in a demonstration. The answers are fast, confident and well written. The problems begin when real people use it for real decisions. At CulturaLinks Community CIC, we work with people from different communities, languages and professional backgrounds. We teach digital and AI skills, support people into employment, and build practical AI tools ourselves. That means we see AI from both sides: as people learning to use it, and as an organisation trying to build it responsibly. And we have learned that AI rarely breaks where developers expect it to. 𝑪𝒐𝒏𝒇𝒊𝒅𝒆𝒏𝒄𝒆 𝒊𝒔 𝒏𝒐𝒕 𝒕𝒉𝒆 𝒔𝒂𝒎𝒆 𝒂𝒔 𝒂𝒄𝒄𝒖𝒓𝒂𝒄𝒚 One woman in one of our programmes used AI while renewing her visa. Her English was good, but government forms are difficult even for native speakers. She asked AI to explain what she needed to do. The answer was clear, confident — and wrong. The rules had changed, but the AI had not recognised that. She followed the advice, submitted the form and eventually had to pay a solicitor to resolve the problem. Another learner showed me an AI answer about benefits. She did not see it as a suggestion or something to verify. To her, the computer had given her the official answer. These experiences changed the way we teach AI. We now start with safety before we teach prompts. If the question concerns money, immigration, health, housing or legal rights, AI should be a starting point — never the final authority. 𝑫𝒆𝒔𝒊𝒈𝒏 𝒇𝒐𝒓 𝒔𝒐𝒎𝒆𝒐𝒏𝒆'𝒔 𝒃𝒂𝒅 𝒅𝒂𝒚 This lesson also changed the way we build technology. When we started developing our own AI support tool, we realised that a confident wrong answer could be worse than no answer at all. Someone asking about housing or employment rights may not be experimenting with technology for fun. They may be frightened, tired or dealing with an urgent problem. So we started asking a different design question: 𝑊𝑖𝑙𝑙 𝑡ℎ𝑖𝑠 𝑠𝑡𝑖𝑙𝑙 𝑤𝑜𝑟𝑘 𝑤ℎ𝑒𝑛 𝑡ℎ𝑒 𝑝𝑒𝑟𝑠𝑜𝑛 𝑢𝑠𝑖𝑛𝑔 𝑖𝑡 𝑖𝑠 ℎ𝑎𝑣𝑖𝑛𝑔 𝑎 𝑣𝑒𝑟𝑦 𝑏𝑎𝑑 𝑑𝑎𝑦? That means plain language. Short explanations. Clear next steps. Reliable sources. And the ability for the system to say, “I don't know, here is where you should check.” We also decided that protecting personal information should not depend only on promising to store it safely. Wherever possible, the safer approach is not to collect it in the first place. 𝑶𝒖𝒓 𝒖𝒔𝒆𝒓𝒔 𝒃𝒆𝒄𝒂𝒎𝒆 𝒐𝒖𝒓 𝒅𝒆𝒗𝒆𝒍𝒐𝒑𝒆𝒓𝒔 One of the biggest changes in our thinking came through an AI hackathon. We invited people to identify real problems and build practical AI-powered solutions around them. What happened challenged one of the assumptions organisations often make: that communities are primarily the recipients of innovation. They are not. People who have had to learn new systems, new technologies and sometimes a new language notice problems that others simply walk past. Teams developed practical ideas around employment, transport and language learning. They also identified improvements for tools we were already building. There were moments when our reaction was simply: How did we not think of that? The answer was obvious. We had not lived the problem. That was when our approach shifted from building for people to building with them. 𝑭𝒊𝒗𝒆 𝒓𝒖𝒍𝒆𝒔 𝒘𝒆 𝒏𝒐𝒘 𝒖𝒔𝒆 Our experience has left us with five principles. First, 𝐬𝐚𝐟𝐞𝐭𝐲 𝐜𝐨𝐦𝐞𝐬 𝐛𝐞𝐟𝐨𝐫𝐞 𝐜𝐥𝐞𝐯𝐞𝐫 𝐩𝐫𝐨𝐦𝐩𝐭𝐢𝐧𝐠. People need to understand what AI can do to them as well as what it can do for them. Second, 𝐭𝐞𝐬𝐭 𝐰𝐢𝐭𝐡 𝐫𝐞𝐚𝐥 𝐮𝐬𝐞𝐫𝐬 𝐛𝐞𝐟𝐨𝐫𝐞 𝐥𝐚𝐮𝐧𝐜𝐡, not once the product is supposedly finished. Third, 𝐝𝐞𝐬𝐢𝐠𝐧 𝐟𝐨𝐫 𝐭𝐡𝐞 𝐮𝐬𝐞𝐫'𝐬 𝐛𝐚𝐝 𝐝𝐚𝐲. If a tool only works when someone is calm, confident and digitally skilled, it does not work for everyone. Fourth, 𝐦𝐚𝐤𝐞 𝐮𝐧𝐜𝐞𝐫𝐭𝐚𝐢𝐧𝐭𝐲 𝐯𝐢𝐬𝐢𝐛𝐥𝐞. “I don't know” can be a better AI response than a polished guess. And finally, 𝐛𝐮𝐢𝐥𝐝 𝐰𝐢𝐭𝐡 𝐩𝐞𝐨𝐩𝐥𝐞, 𝐧𝐨𝐭 𝐬𝐢𝐦𝐩𝐥𝐲 𝐟𝐨𝐫 𝐭𝐡𝐞𝐦. The person experiencing the problem may understand something about it that the product team never will. AI does not really prove itself in a polished demonstration. It proves itself late at night when somebody is trying to understand an important letter, find work, solve a problem or make a decision,б possibly in their second or third language. That is the moment that matters. And the people living those moments are not edge cases. 𝑻𝒉𝒆𝒚 𝒂𝒓𝒆 𝒑𝒂𝒓𝒕 𝒐𝒇 𝒕𝒉𝒆 𝒅𝒆𝒔𝒊𝒈𝒏 𝒕𝒆𝒂𝒎.