Here is a project ConsultBae worked on recently. A healthcare tech client wanted to build an AI that monitors your health through a smart toilet. The device sits inside a commode, captures biological samples through a camera and sensor setup, and sends real-time health insights to a mobile app. Things like hydration levels, digestive health, blood trace alerts, and even period date prediction.
To train the AI, someone had to collect the data. That someone was us.
ConsultBae ran controlled biological studies where participant diet, hydration, sleep, and menstrual phase were logged. We annotated stool samples by Bristol Stool Scale type, color, texture, and density. We tagged urine by transparency, foam, and sediment. We masked water reflections and lighting artifacts so the model would not confuse them for actual biological regions. We built a five-stage QA workflow to make sure every label was medically accurate before the data went anywhere near model training.
That is the unglamorous, essential work that sits underneath AI. And almost nobody in the industry talks about it.
The AI model is what gets announced. The dataset is what makes it work. One without the other is just a press release.
AI data work is harder than it looks
When people think about AI, they think about the model. The architecture. The parameters. The benchmark scores. What they rarely think about is the raw material the model was trained on, and what it actually took to produce that material at a usable quality.
Data annotation is not a straightforward process. It is not just drawing boxes around objects in images. For any non-trivial AI use case, the annotation task requires domain expertise, carefully designed guidelines, edge case handling, and multi-pass quality review. A single ambiguous label in a medical dataset can degrade model performance in ways that only show up in production, when the cost is high.
In the smart toilet project, the challenges were not what you might expect. The obvious difficulty is the sensitivity of the data. But the harder problem was visual ambiguity. Toilet water creates reflections. Lighting changes across washrooms. Shadows cast by toilet bowl geometry look, to an untrained model, exactly like biological matter. Getting a model to tell the difference between a water reflection and a health indicator requires annotation work that is specific, deliberate, and extremely hard to automate.
What good annotation actually involves
Most AI teams underestimate the annotation layer until they run into a problem that traces back to it. Here is what serious data annotation work looks like in practice.
Annotation guidelines are not a one-time document. They evolve with the data. In healthcare projects, a single observation group with a different diet or medication history can introduce patterns that existing guidelines do not cover. The guidelines need to be adaptive, versioned, and reviewed by people who understand both the annotation task and the domain.
Edge cases are where models fail. The common cases are easy. A model trained only on common cases will perform reasonably in testing and fall apart in the real world. Sourcing rare edge cases, blood traces, severe constipation samples, mucus-heavy specimens, menstrual overlap scenarios, takes a separate workflow entirely. It cannot be left to chance in the main dataset collection.
QA is not a single step at the end. A five-stage QA process is not overkill for a healthcare application. Stage one checks annotation completeness. Stage two checks polygon precision. Stage three verifies medical attributes. Stage four audits edge case labels specifically. Stage five does a final consistency check before the dataset ships. Each stage catches different failure types. Collapsing them into one review pass means catching almost nothing.
Observation groups were designed around specific health conditions: high fiber diet, low hydration, spicy food intake, dairy consumption, fasting condition, and iron-rich diet.
Each group generated different annotation challenges. Iron-rich diet simulates dark stool appearance, which can trigger false blood-trace alerts if the model is not trained on the distinction. This kind of domain-specific nuance cannot be built into a dataset without controlled collection design from the start.
categories of data AI companies actually need
The healthcare example is extreme, but the underlying pattern repeats across every industry building AI products. The data requirements are always more complex than the initial brief suggests, and the quality bar is always higher than teams expect when they first scope the work.
ConsultBae works across data collection, annotation, localization, transcription, translation, and QA. The projects span computer vision, NLP, audio, and sensor data. What stays consistent across all of them is this: the teams that ship good AI products treat data as a first-class problem, not a procurement task.
this matters for companies building AI right now
The AI industry is at a stage where most teams have access to roughly the same model architectures, the same compute, and the same open-source tooling. Differentiation is moving down the stack. The companies building durable AI products are the ones investing in proprietary data, high-quality annotation pipelines, and the domain expertise to know what good data looks like in their specific use case.
This is true for healthcare. It is equally true for autonomous vehicles, retail computer vision, financial document processing, voice AI, and any other vertical where the data has complexity that a generic crawled dataset cannot capture.
The smart toilet project is a useful example precisely because it is extreme. If you can build a compliant, medically accurate, edge-case-rich dataset for biological health monitoring under strict privacy constraints, you can handle data complexity in almost any domain.
The companies building durable AI products are the ones treating data as a product in itself, not a step in the process.
ConsultBae actually does
ConsultBae is an AI data services company. We collect the raw data AI models need, annotate it to the quality standard the use case requires, run QA processes designed for the domain, and deliver datasets that are ready for training.
The work spans computer vision, NLP, audio processing, and sensor data. The industries we work in range from healthcare and automotive to e-commerce and enterprise software. The common thread is that every client is building something that requires data that does not exist yet in the form they need, and our job is to build it.
If your team is scoping an AI project and the data problem is starting to look bigger than you expected, that is usually a signal that you are thinking about it correctly. The data is the hard part. It is also the part that determines whether the model is worth anything.
Building something that needs real training data?
Talk to ConsultBae about data collection, annotation, and QA for your AI use case.
Get in touch
