“With AI” has become a visible product feature. However, the expression says little about whether an app becomes more understandable, faster or more reliable. A text summary can reduce laborious preliminary work. An automatically generated classification can also formulate an error convincingly and thus make it harder to identify. Between the two results lies not only the quality of a model, but the design of the entire product.
A meaningful AI function does not therefore begin with the question of which model can be integrated. It begins with a concrete situation: What step does a person try to take? What is slow or prone to error today? What result would be helpful? And what consequences would it have if the proposal was wrong?
Only when these questions are answered can it be assessed whether machine learning, a generative function or a classic rule is the right technique.
From the task to verifiable support
AI can be useful where input is multifaceted and a system cannot expect a single rigid response. An app could group free notes by topic, summarize a long description, expand search terms or suggest values for fields from a document. In all these cases, it supports a limited step. The person retains an understandable goal and can check the result.
The wording “an assistant for everything” is less suitable. It does not allow quality or limits to be tested. Instead, a product team needs examples of good, acceptable and dangerous results. In a search, an incomplete result can be annoying. In case of a legal, financial or health classification, a wrong answer can have significant consequences. The same technical approach requires a different interface, review process and possibly a conscious decision against automation, depending on the context.
A useful requirement format is: “The system suggests; the person decides.” It does not yet define complete security, but prevents important confusion. A proposal is not a confirmed fact. Where the app is supposed to change data, it must be clear what has been proposed, what is adopted and how a correction is possible.
Good candidates: search, structuring and drafts
Search is a common field of application because people do not always use the same terms as the underlying data. An intelligent search can take into account synonyms or similar formulations. Nevertheless, it should show recognizable hits and not pretend to have a single final answer. Filters, sortable lists and a classic text search remain valuable, especially if exact names, numbers or dates are searched for.
When structuring, AI can derive suggestions for categories or fields from irregular text. A handwritten note about a repair could contain, for example, date, object and next step. The app may highlight these values, but should show them for review before saving them. A wrongly read date is easier to correct as long as it is still a visible suggestion.
Summaries help if a person wants to review lengthy content more quickly. The original source must remain accessible. A summary can omit details or misweight relationships. It is a reading support, not a substitute for the relevant contract, report or notice.
Writing aids can be useful: a draft for a factual message, a shorter description or a more structured note. Good design indicates that the text has been created and makes editing easy. Responsibility for sending must not disappear behind a seemingly finished formulation.
Uncertainty belongs in the interface
Generative systems often produce fluent answers, even if they lack information. Especially this apparent confidence can deceive users. Apple recommends for generative functions, among other things, to clearly communicate when AI is used, to explain expectations and limits, not to suggest excessive accuracy and to give a way to check or feedback.
A mere footnote “Can contain errors” is rarely enough. The interaction itself should correspond to the risk. For a suggested category, an editable selection can suffice. For several extracted contract details, a comparison with the source makes sense. If a response is based on uncertain or incomplete information, the app should ask for clarification rather than covering a gap.
The language of the surface also influences expectations. “Automatically recognized” sounds more definitive than “proposal”. A highlighted primary button can push people to accept a result without checking it. Neutral presentation, clear provenance and an easy way back make it clear that human control is part of the intended process.
Marking is more than an AI symbol
A sparkle icon has become a common symbol for AI functions. Without text, however, it does not explain the data flow or behavior. People need to know what happens when they activate it: Will only the selected paragraph be processed or the entire document? Does the processing remain on the device? Is data sent to an external service? Will the result be saved? Can the function be disabled?
This information belongs to the decision points. A short, understandable explanation before the first use is more helpful than an exclusively legal description in a remote document. For recurring actions, essential guidance should remain easy to find without overloading any process with warnings.
Labelling also affects the generated content. If a summary appears later next to manually written notes, its origin should continue to be recognizable. If it is taken over after human review or substantially processed, the product can use a clear status. The aim is not to label every line permanently, but to allow trust through clear provenance.
Clear data flow and data protection before integration
An AI function can process data completely on the device or send requests to a cloud service. Both ways have advantages and limitations. On-device models can work offline, shorten response times and keep content on the device. They are limited by computing power, energy, storage and the available model. Cloud models can be more powerful or easier to update, but need a network connection and transfer data to an additional infrastructure.
Android Developers explicitly describes this consideration: On-device processing strengthens offline use and data protection, among other things, while cloud solutions can enable larger models and more computing power. For the product, this does not follow a general winning architecture. Data sensitivity, task, quality requirement, device class, costs and expected behavior without a network are crucial.
Before a cloud integration, providers, processing purposes, storage periods, use for training, region, access protection and deletion must be clarified. The principle of data minimisation remains important: If a single paragraph is sufficient for a summary, the complete file should not be transferred as a precaution. Direct identifiers may be removed or replaced before content leaves the device.
Local processing also requires data protection work. A downloaded model requires memory. Temporary files and protocols can contain sensitive content. Inputs and results must be deleted in the intended life cycle. “Local is not a shortcut for a complete security evaluation.
Costs and dependencies are part of product decision
Cloud-based AI is often billed by usage. A function that generates few requests in a demo can become significantly more expensive in everyday life. Long input, repeated attempts, images or more users change operating costs. Limits and cost controls must not later unforeseeably worsen the core process.
Models, pricing, policies and interfaces can change. A provider can cancel a model or update its behavior. The product therefore needs a strategy for versions, quality checks and a possible change. An AI service is not an immutable package that remains the same after integration.
A reliable manual way is not only a convenience option. It protects the core task in case of network problems, provider outages, exhausted limits or insufficient quality. If a note can be saved only with AI, although simple fields would suffice, the architecture is unnecessarily fragile. If AI accelerates the first draft, but the input remains directly possible, the dependency is more controllable.
Quality needs to be checked in the actual context
A model can perform well in general benchmarks and still be unusable in a specific app. Technical terms, languages, short entries, incorrect photos and real document structures change the result. Tests must therefore come from the intended usage context and also contain rare, contradictory or deliberately problematic cases.
The NIST AI Risk Management Framework describes a continuous handling of AI risks in the areas of governance, mapping, measurement and management. The additional NIST publication on generative AI deals with, among other things, confabulations, data protection, information integrity and dependencies in the value chain. For a small product team, a practical attitude can be derived from this: classify risks before development, measure effects with suitable cases, define responsibilities and continue monitoring behavior after launch.
Metrics should match the product target. For extraction, accuracy per field, necessary corrections and overlooked values are more interesting than the mere number of generated suggestions. In a search, helpful hits and unsuccessful requests count. In the case of summaries, it should be checked whether essential statements are preserved and no new claims appear.
Quality can also vary by language and content. A function must not be released based only on clean English sample sets if people use German-language photos, abbreviations or mixed documents. Where there is insufficient data for a reliable evaluation, a narrower field of application is more honest than a general commitment.
When a classic function is the better choice
Many problems described as AI use cases can be solved more reliably with proven means. A sorted list does not need a language model. Exact meter numbers can be easily found with normal search. A recurring reminder requires a rule, not a generated date. Mandatory fields, templates and reasonable default values can speed up input without introducing uncertainty.
A conventional solution is particularly strong when rules are stable, results are clear and the consequences of errors are serious. It is easier to test, often cheaper and independent of an external model. AI is more appropriate where the variability of the input justifies the additional effort and a verifiable proposal offers real benefits.
A simple comparison helps: Can the task be described completely as a clear rule? Then this rule should be checked first. Does the system have to extract meaning from a variety of unstructured material? Then AI can be a candidate. Is the result consequential and difficult to verify? Then the right decision may also be not to automate it.
A responsible AI function may be unspectacular
The best integration is not necessarily the most visible. It can improve a search, suggest fields or make a long text easier to review at the right moment. After that, it steps back behind the task. The product remains understandable when the function fails and the person retains the decision.
Therefore, responsible AI does not mean avoiding innovation. It means shaping benefits and risks together: concrete task, appropriate architecture, minimal data, visible uncertainty, verifiable result, reliable alternative and ongoing quality control.
Anyone who cannot name these requirements does not yet have an AI function, but a technical possibility. Only integration into a clear human process turns it into a good product.
Sources and further reading
- Apple Human Interface Guidelines: Generative AI – design, transparency, expectations and user control.
- Android Developers: AI on Android – trade-offs between on-device and cloud processing.
- NIST AI Risk Management Framework – a framework for managing risks from trustworthy AI systems.
- NIST AI 600-1: Generative AI Profile – specific risks and measures for generative AI.
