Adam Kossowski on the Foundations of African Language AI
The African Innovators Series(TAIS): Tech, Data, and AI Changing the Game
Welcome to Issue #67 of TAIS, where every Friday we spotlight visionary changemakers reshaping Africa’s tech, data, and AI landscape, one breakthrough at a time.
Today we spotlight Adam Kossowski, CEO of Way With Words, a South African company whose path into one of AI’s most overlooked foundations (the data layer beneath every speech and language system) began not in a machine learning lab but in the unglamorous, decades-old work of professional transcription, where someone had to listen carefully enough to turn a recorded meeting or interview into a written record someone else could trust.
His world operates where linguistics meets infrastructure, where the painstaking work of recruiting contributors, structuring metadata, and applying consistent transcription rules determines whether the AI systems built on top of that data actually understand the people they are meant to serve. Not in the well-resourced environments where models are benchmarked and celebrated, but in the harder, less visible decisions that happen long before any model sees a single file: who gets recorded, what gets included or excluded, how a hesitation or a code-switch or a culturally loaded silence gets represented, and whether any of that nuance survives the journey from raw audio to training-ready data.
Adam is not building models. He is building what models depend on. And his argument, which runs through every answer in this conversation, is that the quality, fairness, and usefulness of an AI system is decided almost entirely upstream — at the level of who was recorded, how consent was handled, and whether the resulting dataset is merely “clean” or genuinely valuable. His work at Way With Words, particularly its expansion into African language data, is his answer to a question the industry rarely pauses to ask: not just whether a language is included in a dataset, but whether the people who make that data possible ever see any of the value it goes on to create.
Origin & Identity
Q: Your work sits at the intersection of human transcription and AI data infrastructure. How did you come to see transcription not just as a service, but as a foundational layer in AI systems?
A: For many years, in our work at Way With Words, transcription was mostly seen as something that happened after an event. A meeting was recorded, an interview was completed, a focus group took place, and then someone needed a written record of it. That is still an important part of what transcription does, and many clients still need it for that purpose.
But over the past decade, we began to see that transcription also had value much earlier in the process. With the growth of speech recognition and, later, AI, the transcript was no longer only the final record. In certain cases, it became part of the starting point.
This became clearer through some of the early enquiries we received from companies in the USA, the UK, and Europe that were working on automatic speech recognition. At that stage, most of the interest was still around English speech. What they needed from us was not simply a transcript for someone to read, but highly accurate, and often custom-structured, human transcripts that could help support, test, and improve their early speech systems.
That was when I began to see the role of transcription shifting. ASR did not make transcription less important. In many ways, it made accurate transcription more important, because the transcripts we were producing were no longer only an output. They were becoming part of the foundation for what a system could learn from, how it could be tested, and how its performance could be measured.
This matters because AI systems do not understand speech in the way a human listener does. They need examples, audio matched to text, consistency, structure, labels, metadata, and clear decisions about how speech should be represented. If those decisions are not thought through properly, the system can end up learning from poor material. If they are handled thoughtfully, the system has a much stronger foundation.
So when I look at transcription now, I see it as a key part of the process of turning human speech into usable data. That includes the words themselves, but also pauses, interruptions, speaker changes, accents, hesitations, background sounds, and the context in which people are speaking. These details may seem small when someone is only reading a transcript, but they can matter a great deal when that transcript becomes part of a machine learning or AI workflow.
Q: Transcription is often perceived as a support function. At what point does it become something more structural, something that actively shapes how AI systems perform?
A: Transcription becomes structural when the transcript is no longer only being read by a person, but is being used by a system as a reference point.
If a transcript is used to train, test, correct, or evaluate a speech system, then it is no longer just a document. It becomes part of the data layer that influences how the system performs. In that sense, the transcript becomes the version of speech the system is learning from, or being measured against.
For ordinary reading, as with many of our human transcription clients, a clean transcript may be enough. These clients often do not need every hesitation, repeated word, interruption, false start, or non-verbal sound. They may simply need a clear written record for briefing, review, research, or record purposes. But for AI and machine learning, some of those same details are exactly what may make the data useful.
With speech technology, the decision to include or exclude a pause, a speaker change, a background sound, laughter, overlapping speech, or a hesitation is not just a formatting choice. It can be a critical data decision, because it affects what the system learns about real human speech and how it learns from it. That is why transcription becomes more than typing words one hears. It becomes the interpretation of speech according to a specific purpose. This leads to an important, if not critical, question when producing transcripts and related data: what is the data going to be used for?
In speech data work, the rules behind the transcript matter as much as the words themselves. If those rules are unclear or applied inconsistently, the dataset becomes weaker, and in some cases may have little value for the intended purpose. If they are clear and carefully followed, the transcript can become a much more reliable foundation for the solution the data is meant to support.
So, for me, transcription becomes structural at the point where it starts influencing the system that comes after it. It is no longer only a record of what happened. It becomes part of how a machine learns to recognise, compare, classify, or interpret speech.
Editorial commentary: Most people think of transcription as a process of recording speech, but Adam’s reflections challenge that view with the argument that transcription is also an act of interpretation. Every decision about whether to include a hesitation, label a background sound, preserve an interruption, or distinguish between overlapping speakers is ultimately a decision about what aspects of human communication matter enough to become data.
This helps explain why he draws such a clear distinction between transcripts created for people and transcripts created for machines. A person can often infer meaning from context or overlook minor imperfections, but AI systems cannot, because they learn from the representation they are given. So the transcript is not simply a record of speech, but a translation of human conversation into a form that machines can interpret.
Transcription therefore occupies a surprisingly influential position within the AI pipeline. Long before questions of model architecture or performance arise, someone has already made countless judgments about how reality should be represented. Those decisions rarely receive much attention, yet they quietly shape everything that follows.
The Data Pipeline
Q: Much of the focus in AI is on models and outputs, but far less attention is given to how data is produced and prepared. What does the data pipeline actually look like in practice, from raw audio to something that is “training-ready”?
A: Yes, you are correct. A lot of public attention goes to models and their final outputs. That is understandable, because that is what people see, or what the application is ultimately intended to do. But in practice, much of the quality is decided much earlier, before the data ever reaches a model.
From our point of view, the pipeline has to start with the requirement. Key questions need to be asked from the beginning. What is the dataset meant to do? Is it for speech recognition, model evaluation, language coverage, testing, or something else? Does it need to cover particular accents? Is it focused on one language or several? Does it need to include domain-specific use cases? These decisions shape everything that follows.
Once that is clear, the next stage is planning. We need to be very clear about who needs to be recorded, what language or dialect is required, and what kind of speech should be captured. Should it be read speech, prompted speech, spontaneous conversation, interviews, domain-specific content, or something more natural? What metadata is needed? What consent is required? What should be included or excluded to make the collection useful for its intended purpose?
Then comes the challenge of recruitment and collection. This is one of the stages where data projects can encounter significant risk. If the wrong contributors are selected, the instructions are unclear, or the recording environment is poor, the problems do not disappear. They follow the data through the rest of the pipeline.
After the collection phase, the raw audio needs to be checked. Is the recording usable? Is the speaker suitable for the specification? Was the task completed properly? Is the language correct? Is the audio quality acceptable? Are there duplicates or signs that the data is not what it claims to be? Only once that is signed off should transcription and annotation begin. At this stage, the audio is turned into text, but not in a generic way. The transcript has to follow the rules of the project. In some cases, that means clean text. In others, it may mean capturing hesitations, false starts, repetitions, speaker turns, overlapping speech, background sounds, or other details.
Quality assurance then follows. This is not a small step at the end. It is one of the most important parts of the process. The QA process needs to check that the transcript matches the audio, that the labels are consistent, that the metadata makes sense, that the formatting follows the specification, and that the final files are usable by the technical team.
In simple terms, the pipeline moves from requirements, to speaker and language planning, to recruitment, to recording, to audio checks, to transcription and annotation, to QA, to metadata structuring, and finally to delivery.
Every stage can either improve the dataset or weaken it. This is one reason we developed TalkTag, because we wanted more control over the process from collection through to validation, rather than trying to repair problems after the fact.
That is why I do not think of training-ready data as simply “cleaned-up” data. Training-ready data is data that has been collected, checked, structured, and documented for a specific machine learning purpose.
Again, a model may look impressive at the output stage, but its behaviour is often shaped much earlier by practical decisions: who was recorded, how they were recorded, what was transcribed, what was excluded, how the rules were applied, and how carefully the final material was checked.
Q: Terms like “clean data” or “high-quality datasets” are widely used, but rarely unpacked. What does quality actually mean in your context, and who defines it?
A: I think “clean data” and “high-quality data” are often used as if they mean the same thing. In practice, we see them slightly differently.
Clean data means the data can be used for the intended machine learning purpose. It meets the specification. The files are in the right format. The recordings meet the required standard. The transcripts or labels follow the rules. The metadata is complete enough. The contributors match the required profile. The data is not duplicated, corrupted, mislabelled or unsuitable for the task. So clean data is about whether the data fits the agreed requirement.
High-quality data goes further than that. It is about the value the data can offer to the system being built. A dataset may be clean, but still not be especially valuable. It may pass the basic checks but be too narrow, too artificial, too generic, or not representative enough of the people, language or conditions the technology is meant to serve. So high-quality data is data that adds value to the use case. It may include the right spread of speakers, accents, regions, dialects, age groups, environments or domains. It may capture the way people actually speak, not only the way a script assumes they speak. In some cases, high quality can mean very broad representation. In other cases, it may mean very specific domain relevance.
So quality, in its essence, depends on purpose. That is why it should be defined at the start, not argued about at the end. The client or technical team needs to be clear about what the system is meant to do. The data team then needs to turn that into practical collection rules, contributor criteria, transcription guidelines, annotation requirements, metadata fields, QA steps and delivery standards.
Importantly, it should not be defined by one party alone. The technical team understands what the model needs. The data team understands how to collect, prepare and validate the material. The contributor and community context help determine whether the data is representative and meaningful.
For us, quality means the data is fit for the machine learning purpose, true to the agreed specification, and valuable enough to improve the outcome of the AI or technology being built. Clean data informs us whether the data can be used, while high-quality data determines whether the data is worth using for the purpose it was collected.
Editorial commentary: There is a tendency to imagine that an AI system begins when the model starts training. Adam’s description of the data pipeline suggests that, in many ways, the system has already begun long before that point. By the time a model encounters a dataset, countless decisions have already been made about who was recorded, what counted as representative speech, which imperfections were preserved, what metadata mattered, and even what the project was ultimately trying to achieve.
This shifts where responsibility sits. If models inherit the strengths and weaknesses of their training data, then many of the choices that shape AI are made not by machine learning engineers, but much earlier by the people designing the pipeline itself. The intelligence we attribute to AI is therefore inseparable from the human judgment embedded in the data that precedes it. The model may be where learning happens, but the pipeline is where many of its possibilities and constraints are quietly established.
The Human Layer
Q: Your work relies heavily on human contributors across languages and contexts. How do you think about the role of human labour in systems that are often described as automated or intelligent?
A: I think this is one of the most important things to remember about AI. Many systems are described as automated, but they are built on a great deal of human work.
In speech and language data, the human role is central. Someone has to contribute the voice. Someone has to speak the language. Someone has to understand the task. Someone has to record the audio, check it, transcribe it, annotate it, review it, and then decide whether it is suitable for the purpose. These effort can easily disappear from view once the final system is described as intelligent or automated. And that is a problem.
A person contributing their voice is not simply filling a data requirement. They are offering something personal. Their speech carries their accent, language, identity, place, expression and context. In African language work especially, that contribution carries a wide cultural and community meaning.
So I think human labour in AI needs to be recognised more honestly. The intelligence may appear in the software, but the foundation is human.
This also means contributors need to be treated with respect. They should understand what they are taking part in. They should know why the data is being collected, how it may be used, what protections are in place, and what their rights are. They should not become invisible once the data has been collected.
There is also the labour of the people preparing the data. Transcribers, annotators, reviewers, project managers and language specialists make thousands of small decisions that affect the quality of the final dataset. Those decisions may not attract the same attention as the model itself, but they matter. If the human work is weak, rushed or poorly guided, the data suffers.
If the human work is careful, informed and properly managed, the system has a stronger base to learn from. So when people talk about automated systems, I think we need to keep asking what human contribution made that automation possible. In our field, the human layer has not disappeared. It has simply moved into the background. Our view is that it needs to be brought back into the conversation.
Q: Behind every dataset is a set of economic decisions. What are the less visible economic dynamics that shape how datasets are sourced, built, and valued?
A: One of the hidden economics of data is that a dataset can be cheap to collect and expensive to fix.
The visible costs are usually easy to list: recruitment, recording, transcription, annotation, quality assurance, platform use and delivery. Those costs are real, but they do not necessarily tell the whole truth.
The less visible value, and a key one for us, is in the design of the collection and in the people who contribute the data. A dataset is not represented by volume alone. It is hugely influenced by the contributors, their voices, accents, environments, behaviour, interpretation, timing and context of the recordings. If the wrong contributors are selected, or if the collection is too rushed, too specific or its purpose poorly explained, the dataset may achieve a volume target but fail its real purpose or stated value. That failure can be expensive.
It may well require re-recording, re-checking, re-labelling, rebuilding metadata, or discovering later that the dataset fails to represent the speakers or conditions the system was meant to serve.
So contributor selection is not just an operational decision. It is an economic one.
The same for quality assurance. Good QA may look like a cost at the beginning, but poor QA becomes a much larger cost later. If errors enter the training data, they can negatively influence the system built on top of them.
There is also the question of how “value” is considered. The economic value of a dataset isn’t just in the final files. It’s in the human contribution that created those files and, critically, in how well that contribution was collected, structured and protected. This is especially important in African language work where participation often carries a higher meaning beyond a simple task fee. People may see their language, identity or community being represented and that needs to be handled with care.
So when we talk about the economics of data, I think we need to ask more than, “What did the dataset cost?” We must also ask, “What value did the contributors make possible, and how well was that value carried through into the final dataset?”
A strong dataset is carefully built through good design, the right contributors, clear purpose, careful management and proper quality control.
Editorial commentary: Adam repeatedly returns to the people behind the data. It is a subtle but important distinction. While AI conversations often reduce speech to something that can be collected, labelled, and processed, he describes every voice as carrying far more than words. It carries identity, culture, place, and context. That perspective makes it difficult to think about speech data as just another technical input.
It also introduces a different way of thinking about responsibility. If voices are more than data points, then building datasets is not simply about collecting enough examples to train a model. It is also about recognising that every recording begins with a person choosing to contribute something uniquely their own. The technical work of transcription, annotation, and quality assurance matters, but so does the relationship between the people contributing the data and the systems eventually built from it.
African Languages: Stakes & Specificity
Q: You’ve positioned African languages as a strategic area of focus. What makes working with these languages fundamentally different from working with more resourced language datasets?
A: The starting point is different.
With more resourced languages, there is usually already a large base of data, research, tools, digital content, funding history and technical infrastructure. English is the obvious example. It has helped create the foundation for much of the early learning curve for speech recognition, language models, search, machine translation and other technologies.
On the other hand, many African languages have not had that same opportunity. So the work is not about adding another language to a system. It is often about helping to create the conditions for that language to be properly represented in the first place.
That means the challenges are, in essence, much more foundational. You may need to identify suitable speakers, design responsible collection methods, agree new transcription conventions, manage dialect and regional variation, capture code switching, build metadata, validate language quality, and make sure the data is actually useful for machine learning.
You also have to be careful not to treat African languages as one category. The continent contains a vast range of language families, histories, speech communities and local realities. What works for one language, region or use case may very well not work for another.
There is also a deeper question of access. If future AI systems do not work well in African languages, then many people may be forced to access technology through dominant global languages. That affects education, healthcare, agriculture, public services, financial inclusion and daily communication. For us, this is not just a technical gap. It is a practical and social one. Language is one of the main ways people access the world and if the digital systems of the future cannot understand people in the languages they use every day, then those systems will not serve them properly and access fails.
There is also a responsibility question. Who collects African language data? Who holds it? Who benefits from it? Who decides how it should be used? These questions matter a lot for me because language data is not just technical material. It carries identity, culture, memory and social value.
So what makes African language work different is the combination of scarcity, complexity, responsibility and opportunity. In essence, more resourced languages have already shaped much of the AI world, while African languages now need the investment, stewardship and practical data work to take their place in it properly.
Q: There are growing efforts globally to build large-scale multilingual and speech datasets. How does your work align with or differ from these initiatives in terms of approach, priorities, or assumptions?
A: My concern is that we sometimes celebrate volume before asking whether the data will actually help a language become usable in real systems.
We do align with those initiatives in one important way: we also believe that many more languages need to be represented in the data that shapes future AI systems. But where our emphasis may differ is that we are not only interested in language coverage as a technical benchmark. We are more interested in what that coverage makes possible.
It is one thing to say that a language has been included in a dataset. It is another thing for that language to become useful in real tools, services and systems that people can actually use.
A lot of global multilingual work quite rightly focuses on scale. The world needs broader language coverage. But scale alone is definitely not enough. A large dataset can still be weak or be of little value if it is poorly collected, badly labelled, unrepresentative or disconnected from the communities it claims to serve.
For African languages, I think the goal should not simply be to add local languages into systems designed around dominant languages. The more sensitive approach is to make it possible for African languages and their contexts to shape the systems themselves. In practical terms this means paying attention to quality, consent, metadata, language variation, stewardship and the intended use case. It also means asking whether the data can support practical outcomes, not just technical inclusion.
As we can see, AI is changing quickly. Models become better at transferring meaning across languages and working with less data than before. But I do not think that removes the need for local data. It’s the opposite: it makes local grounding even more important. A system may become better at language generally, but it still needs to understand how people actually speak, what words mean in context, how code switching works, what local references mean, and how meaning changes across communities.
So our work aligns with global efforts in the belief that multilingual data matters. But our focus is also on usefulness, responsibility and local relevance.
Importantly, the aim should not be that African languages are added later as secondary layers. They should be part of the foundation from which better, more relevant technologies are built.
Q: You argue that preservation is not enough, and that languages are only secured when they are actively used and embedded in digital systems. In your view, are current efforts around African language datasets and tools genuinely moving toward that kind of functional presence, or are they still operating at the level of symbolic inclusion?
A: I think we are moving in the right direction in parts, but we are not yet at the level of a mature functional presence for many African languages.
There is important work happening now, and it should be recognised. More people are speaking about African language datasets, language rights, inclusion, preservation and digital access than before. But, to be honest, we should also acknowledge that in many cases for under-represented languages, the work is still based on early-stage enablement rather than true everyday usability.
For a language to have a real digital future, it can’t only be documented, archived or included in a dataset. It has to be usable, so it needs to be applied in many tools that provide or support services, education platforms, health systems, public communications, research workflows and many of the technologies people rely on in daily life. And this is where That is the gap is.
We need to shift from symbolic inclusion where perhaps the language is considered as being collected to a more functional reality where the language is actually in use. So in line with your question, preservation is important, but preservation alone does not secure a language in a digital world. A language will only become more secure when people begin to actually use it in the systems that affect their lives.
To get there, I think three things matter.
First, we need to look closely at responsible collection. The people contributing their voices or language knowledge need to understand the purpose and be treated with respect.
Second, we need to incorporate rigorous quality assurance. African language datasets will not become useful simply because they exist. They need to be accurate, representative, well labelled, properly transcribed and suitable for the machine learning purpose.
Third, we must have a clear use case. We need to know what the data is meant to support. Will it help build better speech recognition? Provide better education tools? Improved public service access? More effective healthcare or agricultural communication? Support local language technology?
Without clear objectives, there can be a lot of activity but limited progress.
I would say current efforts are encouraging, but still uneven. We need less symbolic language about inclusion and ownership and much more disciplined, responsible, purpose-led data work that helps African languages move into real practical use.
Editorial commentary: One implication of Adam’s reflections is that language infrastructure should perhaps be thought of less like a cultural archive and more like public infrastructure. We rarely judge a road by whether it exists; we judge it by whether it connects people to the places they need to go. He seems to apply the same logic to African languages. A dataset is not successful because a language has been collected or documented. Its success lies in whether it enables someone to access healthcare, education, financial services, or public information in the language they actually use.
That reframes what inclusion means. Instead of asking how many African languages appear in AI systems, Adam’s answers invite a different question: which languages are becoming functional parts of everyday digital life? The distinction is subtle but important. Representation is a milestone. Participation is the destination.
Governance & Consent
Q: Large-scale data collection efforts often raise questions around participation, ownership, and benefit. How do you approach issues of governance, consent, and contributor inclusion when building datasets in African contexts?
A: For us, governance begins before collection.
It starts with the purpose. Why is the data being collected? What will it be used for? Who is contributing? What are they being asked to provide? What must they understand before they take part? What protections need to be in place?
These questions should not be asked at the end. They should be used to create the design of the project from the start.
In African language contexts, this is especially important because speech data is not just a technical input. It often comes from communities that have been underrepresented in digital systems for a long time. When people contribute their voices, they are helping create the foundation for future tools and services that may affect how those languages are used in technology. And this creates an important governance responsibility.
Consent should be clearly understandable, not just legal. Contributors should know what they are taking part in, how their data may or will be used, and what the limits of that use may be. They should also understand what is being collected from them, whether that is voice, language background, demographic information, location type, image data or other supporting metadata.
Good governance also means keeping all these processes traceable. The data should be collected in a way that can be checked, reviewed and explained. There should be clear rules around contributor management, consent, quality control, data handling and delivery.
Ownership, though, is much more complicated. There may be commercial agreements, client rights, platform rights and licensing terms. Those are necessary. But the value of the data still begins with the people and communities who made it possible which, in turn, should influence how the work is framed.
For us, inclusion is not simply a matter of counting a language in a dataset. It means checking whether the people and communities represented by that data have a meaningful place in the value that follows.
Practically, that does not mean every project can solve every issue. But it does mean that the process should not be extractive by default. It should be clear, fair, respectful and properly connected to the purpose of the work.
So our approach is quite simple in principle: start with the person, explain the purpose, protect the data, manage the process carefully, and keep asking whether the work is helping build technologies that can serve the people whose voices made them possible.
Q: In multilingual and cross-cultural data work, translation is never just technical. What are the kinds of meaning or context that tend to get flattened or lost in the process?
A: Translation can easily make something look more understood than it probably is. A sentence may be technically correct in another language, but still lose its tone, humour, hesitation, emotion, indirectness, politeness, local idiom, social hierarchy, rhythm or cultural reference. It can offer basic meaning, but not the full meaning.
That matters in speech data because language is not only words. It is also context. In multilingual and cross-cultural data work, the important question is not only, “Is this translated correctly?” It should also be: “What needed to be preserved in the intent and meaning?”
For some AI tasks, literal meaning may be enough. For others though, the important value may sit in intent, sentiment, speaker relationship, domain terminology, conversational flow, cultural reference or the way a person uses language in a particular setting.
So if that is not defined at the start, the translation process can quietly remove the very features the dataset needed. And this is why I think data is only as rich as the question you are asking of it.
The same recording can have different value depending on the use case. These require decisions regarding the use of labelling, tone, cultural context, code switching, hesitations, emotion or even local phrasing.
So the challenge from the outset is to decide which layers of meaning matter.
As a service, our responsibility is to be clear about which of those layers need to be preserved, and honest about what may be lost if they are not to our client. If we don’t do this, translation can create the appearance of “understanding” while quietly flattening the original speech.
Q: What is something about AI data, how it is created, validated, or used, that you think is widely misunderstood, even among people working in the field?
A: I think one of the biggest misunderstandings is that AI data is an asset to be owned.
Of course, there are legal rights, licences, contracts and commercial arrangements. Those are necessary and should be required. But when we are dealing with speech, language, image, culture and human expression, ownership is not just a legal question, it’s a question of its origin, who it ultimately benefits and the responsibility for it.
Companies can collect audio and platforms process it. A client may pay for the dataset and have their model trained on it but the source of the value is still the people, language and cultural context that made the data meaningful in the first place. That is often a forgotten aspect of what this is all about.
In conversations today, data is sometimes spoken about as if it is detached from people once it has been collected and structured. But we must remember that a voice dataset is created through individual contributions and carries accents, meanings, local usage, ways of thinking, social context and sometimes cultural memory.
Those elements of data are not created by the technology provider. They come from the language community.
So when we speak about data, I do think we should also speak about benefit. Who benefits from the tools built from it? Does the language community see any practical value? Does the data help improve communication, education, health, agriculture, access to services or future digital inclusion in a practical way? Or is the value simply taken out of the community and captured for someone else?
This matters especially in African language contexts. If language data is treated only as a commercial asset, we do risk repeating older patterns where value is extracted from communities without enough return. But if we treat language data as something connected to stewardship, representation and future access, then the conversation changes.
So the misunderstanding again, for me, is that AI data is just something to own. I would say it is more accurate to say it is something to manage responsibly.
Editorial commentary: One subtle feature of Adam’s thinking is that he refuses to separate conversations that are usually treated as distinct. Governance, translation, consent, quality assurance, and ownership appear throughout this interview, yet he approaches them as different expressions of the same underlying relationship between people and the systems built from their data. Rather than treating them as separate technical or legal questions, he sees them as connected decisions that accumulate across the life of a dataset.
This way of thinking also challenges the increasingly specialised nature of AI itself. Engineers optimise models, linguists work on language, lawyers draft governance frameworks, and ethicists debate consent. Adam’s reflections suggest that these boundaries are far more porous than they appear. A translation decision can become a governance decision. A transcription rule can shape model performance. A consent process can influence what kinds of knowledge are available to future systems.
Perhaps that is the broader implication of his work. The AI pipeline is often described as a sequence of independent stages, each handled by different experts. Adam instead presents it as a single chain of interconnected decisions, where seemingly small choices made at one point can quietly determine what becomes possible much later. Responsible AI emerges from recognising how every layer of the pipeline depends on the others.
Expanding Scope: Multimodal & Industry Tensions
Q: You’re expanding into multimodal data collection, including image datasets. What new challenges emerge when moving from speech and text into multimodal data environments?
A: Moving from speech and text into multimodal data adds another layer of complexity, because the data is no longer only about what is said. It is also about what is seen, where it is seen, how it is captured, and what that visual information may reveal. This is one of the areas where we see TalkTag evolving, because multimodal collection needs much stronger control over instructions, validation and context.
With speech, the main questions are around the speaker, the audio, the transcript, the language, the metadata and the consent. With image data, many of those same principles still apply, but the risks and practical issues change in a number of ways. For example, you have to think about subject matter, image quality, lighting, angle, location, background, duplicates, permissions, sensitive content, labelling and whether the image actually represents what the collection is meant to capture.
And before you consider these principles, the starting point is still the requirement. What must the model learn or recognise? What kind of images are needed? Under what conditions should they be captured? What should be included? What should be excluded? What labels or metadata need to sit alongside each file?
Without this kind of detail and clarity, image collection can quickly become a volume exercise as well. You may collect many files, but still not have a useful dataset.
Multimodal data also raises possibly even stronger consent and privacy questions. Images can reveal people, property, living conditions, workplaces, behaviour, identity and community context in ways that may be more visible than speech alone. That means contributor instructions, consent terms and review steps need to be especially clear and approved.
Then there is also the question of alignment between these media. If a dataset includes speech, text and images, those elements need to relate properly to one another. The image, label, description, spoken prompt or written response must all point to the same intended meaning. If they do not, the dataset can become misleading.
So the challenge is not only collecting more types of data. It is making sure the different forms of data are properly inter-connected, described, checked and structured for the machine learning task the collection was set out to support.
For us at Way With Words, this is why workflow matters. Contributors need clear guidance, and the collection process needs mechanisms to check frequently whether the data is suitable before it moves too far down the pipeline. The question is not simply whether we can collect speech, text or images. The question is whether the data we collect is accurate, appropriate, consented, well described and genuinely useful for the purpose it is meant to serve.
Q: You work across both commercial and research-oriented contexts. Where do you see tensions between what industry needs and what research communities prioritise when it comes to data?
A: Industry mostly requires data that performs, while research often wants data that explains. Maybe that is a simple way of putting it, but I think it captures one of the main tensions.
Commercial clients usually request data for a specific purpose. It may be for a speech model, a customer service tool, a health application, a voice interface, a translation system or a particular AI workflow. The value of that data is judged by whether it helps that technology work better in that setting.
On the other hand, research communities often take a broader view. They may be interested in language preservation, documentation, linguistic variation, oral tradition, cultural context, meaning and how people actually speak across communities. This kind of data may not always be collected for one immediate commercial application, so it may well have long-term value.
In my opinion, both views matter as they balance the outcome risks both bring: If industry is too narrow, it can build tools that work technically but miss important human or cultural nuance. If research is too broad, it can preserve valuable material but struggle to turn it into practical systems that people can use. In African language work, we have to sit between these worlds, translating commercial needs into practical data work while still respecting the deeper language context.
Ultimately, we need practical datasets that help build tools for real use cases, but we also need the research depth that protects the language, context and meaning behind the data. The best work happens when these two worlds support each other. Industry can bring urgency, funding, deployment needs and practical use cases. Research can bring linguistic care, cultural understanding, context and a longer-term view of value.
The tension is not necessarily a bad thing. It just needs to be understood and managed carefully.
Q: As demand for training data continues to grow, how do you see the role of companies like yours evolving, particularly in African language ecosystems?
A: I think companies like ours will need to shift from being simple data suppliers to becoming trusted data partners.
This will be especially true in African language ecosystems, where the work is rarely straightforward. As we know, Africa is not a single language market. Rather our continent contains many languages, dialects, communities, histories and communication needs. So clearly a typical standard collection model will not work everywhere.
Increasingly, our role will not only be to collect data and deliver files but, as we have experienced, to help design the collections properly. This means we need to ask the right questions early. What is the data meant to achieve? Who needs to be represented? What kind of speech is needed? What does quality mean for this project? What should contributors understand? How will the data be checked? What value should the final dataset create?
Once those questions are answered, the foundation for practical work becomes much stronger and the proposed value of the collection more certain. It ensures that the right contributors can be identified, tasks are designed properly, correct metadata can be structured and the QA process can be aligned to the use case. This ultimately ensures the final dataset can be delivered in a way that is genuinely useful for its purpose.
I also think companies like ours will need to manage the bridge between contributors and technology users more carefully. On one side are the individuals and communities contributing speech, language knowledge, images or other data. And on the other are companies, researchers, NGOs, funders, universities or public institutions trying to build useful tools or technology solutions. It’s the middle space – us – that requires trust, structure and good judgement.
Looking forward I can see the demand for training data will continue to grow, but not all data will be equally useful. Poorly collected data can create poor systems. Narrow data can exclude important voices. Data without purpose can become noise. Data without proper consent can become harmful. So our future role and import is to help make the process more practical, more responsible and more valuable.
For Way With Words, that means helping to design, collect, validate and prepare African language data in a way that is useful for AI, respectful of contributors, and valuable to the communities and organisations the technology is meant to serve.
Editorial commentary: AI conversations often gravitate toward visible actors: the companies building models, the researchers publishing breakthroughs, or the organisations deploying new applications. Interviews like this reveal a much larger ecosystem operating between those worlds. There are organisations whose primary role is neither discovery nor deployment, but translation, turning research questions into practical data collection, and turning community knowledge into resources that technical systems can actually use.
As AI matures, that middle layer may become increasingly significant. The future of AI will depend not only on better models, but on institutions capable of coordinating contributors, researchers, companies, and public organisations around the far less glamorous work of building reliable data infrastructure. In that sense, companies like Way With Words occupy a role that is still largely invisible, yet increasingly difficult to replace.
Additional reflection: “Transcription began as a way to record speech. With AI, it has become part of the foundation that systems learn from. As language data becomes more valuable, I think the real question is no longer only whether the data is accurate, but whether it is purposeful, representative, responsibly collected, and useful to the people it is meant to serve.”
Closing remarks
AI is often presented through its most visible achievements: conversational models, image generators, autonomous systems, and ever-improving benchmarks. Yet conversations like this remind us that long before a model produces an answer, an entire ecosystem of people, processes, and institutions has already shaped what that answer can become.
Adam’s work invites us to look beneath the surface of AI. Not because transcription or data preparation are more important than models, but because they reveal a broader truth about technological progress. The performance of intelligent systems is rarely determined at the moment of deployment. It is determined much earlier, through thousands of practical decisions about how knowledge is collected, interpreted, organised, and validated.
That perspective feels particularly relevant as African languages assume a more prominent place in global AI conversations. The challenge is no longer simply ensuring these languages appear in datasets, but ensuring they are represented with the care, context, and stewardship necessary for technologies that genuinely serve the communities from which they originate.
Perhaps that is the lasting insight from this conversation. The future of AI will not only be shaped by those building increasingly capable models, but also by those quietly deciding what those models are able to hear, understand, and ultimately learn.
Thank you for reading!
Based on today’s conversation, which cluster in TAIS Knowledge map do you think best describes Adam’s thematic community?
Don’t see your pick in the options? Drop it in the comments. Adam joins the map this weekend.
Thank you for standing with this work.