Conflict is not resolved by adding another screen. When an application asks for information to mediate a dispute, confirm a complaint, or decide who may proceed, a screen can organise a process but cannot replace context. A disagreement between people, a complaint about a service, or uncertainty about a rule requires knowing which data are necessary, who may see them, and which decision must not be delegated to a form.
In privacy and data, the ease of opening an extra field is often mistaken for a solution. Requesting screenshots, full conversations, location, or contacts can turn a limited incident into a disproportionate file. Information should clarify a specific fact, not build profiles of participants or shift the burden of resolving conflict to the person with the least room to act.
A responsible application provides a human route, explains the scope of every request, and allows correction or removal of data that prove irrelevant. It also separates evidence needed to handle a case from records intended to improve the service. That separation protects people and improves the response: a reviewer needs reliable evidence, not an accumulation of detail without purpose.
The practical rule is simple: before adding a screen, define the question it must answer, the minimum data that can answer it, and the date on which those data cease to be necessary. Without a clear answer, a new screen adds friction and risk rather than fairness. Transparency must appear where information is requested, in understandable language and with an alternative that does not penalise anyone.
Resolving matters well also means recognising limits. A score, label, or sequence of clicks does not by itself explain a relationship, need, or responsibility. An application can help document, refer, and repair; the decision must retain review, challenge, and a genuine way out. Privacy does not obstruct care: it prevents care from becoming surveillance.
An exception does not authorise opening everything#
Apps often promise data-driven decisions. The phrase can describe a useful practice: checking how many people find information, detecting a system outage, or learning whether a form produces errors. The problem begins when the number is treated as a complete description of reality. If the stated objective is to make an appointment easier, the indicator should not push the service to request precise location, contacts, or browsing history that are not needed to book it.
Apps often promise data-driven decisions. The phrase can describe a useful practice: checking how many people find information, detecting a system outage, or learning whether a form produces errors.
The Spanish Data Protection Agency recalls that processing must be adequate, relevant, and limited to what is necessary. That idea turns an abstract discussion into concrete design. To understand service demand, an aggregate number of requests by time slot may be enough. To locate a technical error, a temporary identifier and the app version may be sufficient. Retaining full content, device details, and every later step requires an additional reason that is clear and testable.
It is also worth examining which behaviours the indicator rewards. A system that values only fewer calls may make telephone access harder, even though a conversation is the most accessible route for many people. Another that pursues completed forms may hide the option to leave without sharing data. Effectiveness is not the same as moving everyone through the route that costs the organisation least. It must include the ability to choose a channel, request an explanation, and correct wrong information.
Quality needs more than one signal. Alongside response times, an organisation can review complaints, accessibility, confirmed errors, comprehension of notices, and the success of human referrals. No metric replaces judgement, but several signals reduce the risk that a convenient number becomes an instruction. An honest report says what cannot be concluded from available data and avoids presenting correlation as if it were an individual's intention or capability.
An exceptional route needs a beginning and an end#
A request for data rarely ends on the screen where it is entered. It may pass through an identity provider, analytics tool, backup system, support team, and maintenance contract. A useful inventory therefore does not stop at field names. It states purpose, applicable basis, recipients, location, retention period, internal access, subprocessors, and deletion method. If the journey cannot be explained clearly, collection is unlikely to be proportionate.
The General Data Protection Regulation establishes data minimisation, purpose limitation, and storage limitation. They are not formulas for a lengthy policy; they are design tests. Can an exact date be replaced by a range? Can an error be measured without storing sensitive text? Can an account needed for an application be separated from optional analytics? Every answer that removes a datum also reduces the possible harm from improper access, a change of provider, or interpretation outside context.
Transparency must sit close to the decision. A generic link to legal terms does not explain why an app requests location permission to show an office or how long it keeps a query. A short notice can distinguish necessary information, optional information, and data that should not be sent. It should also say whether a reply is automatic, how to request human review, and what happens if non-essential measurement is refused. Declining analytics should not block basic help.
The NIST AI Risk Management Framework proposes governing, mapping, measuring, and managing risks continuously. For an app using metrics, this means checking not only result accuracy but also the effect of obtaining it. A measurement can be technically correct and still disproportionate because it discourages sensitive queries or expands third-party access. The risk map should include those social effects, not only program failures.
Case one: the appointment that cannot be confirmed#
A network of public centres created an app to book appointments and find the nearest service point. The team wanted to reduce missed appointments and added continuous geolocation, device-linked reminders, and a log of in-app routes. The dashboard improved: it showed how many people opened the map and how long confirmation took. Yet the collected information could reveal frequent visits, mobility habits, and moments when someone sought help, although most queries needed only an opening time and an approximate address.
The review began by separating objectives. To offer the nearest centre, the app requested a postal code or manual search, not a permanent position. To check the map's usefulness, it measured aggregate queries and loading failures, not individual trajectories. Reminders became optional and were deleted after the appointment. When someone needed to change a booking, it could be done by telephone or in person without opening the app or accepting notifications.
The change did not leave the team without information. It made it possible to detect that one area displayed wrong results, that certain times caused confusion, and that an older version failed with screen readers. It also prevented the reduction of missed appointments from becoming an excuse to follow people who did not attend. An absence may be caused by work, caring duties, transport, or a legitimate decision not to continue. The indicator is for reviewing the service, not constructing personal explanations the system cannot know.
Case two: identity review and temporary access#
An employment portal offered training and guidance resources. To prioritise notices, it calculated a score using access frequency, job-listing clicks, and time spent on each course. A later proposal would add searches, declared age, neighbourhood, and staff free-text notes. It promised a better tailored recommendation, but turned incomplete signals into a stable picture of motivation, availability, or risk of long-term unemployment.
The institution set a functional boundary: the score could only order voluntary suggestions and could not affect access to benefits, interviews, or courses. Free-text notes were removed, and use of the indicator as the sole reason for a decision was prohibited. People could see that they received an automated recommendation, turn it off, and contact a human adviser. The team evaluated the tool with test data and aggregate groups, without keeping each person's detailed browsing history in order to justify an inference later.
The lesson was not that every recommendation is harmful. It was that an activity number is not equivalent to a measure of interest or capability. Someone may consult little because they share a computer, work shifts, care for another person, or prefer to visit an office. When a metric begins to influence opportunities, uncertainty must be visible and consequences must be limited. Help loses legitimacy when it resembles a classification with no explanation or way out.
Case three: urgent help outside the form#
A council launched an app to explain housing support, deadlines, and documentation. Its analytics contract allowed full conversations, advertising identifiers, and pages visited before and after every query to be recorded. The purpose was to measure satisfaction and find unclear replies. But that collection could reveal financial hardship, family changes, or an urgent housing search, information that is particularly sensitive when it arises from a relationship with a public service.
The team replaced detailed tracking with a voluntary question at the end of the interaction, periodic tests using fictional queries, and aggregate metrics on frequent topics. To investigate a specific error, it created a protocol: limited access, a documented reason, review by a responsible person, and later deletion or anonymisation. The app made clear that it neither processed applications nor made decisions about support; replies linked to the official source and offered telephone and in-person service.
The result was a less spectacular but more defensible measurement. The council could learn which deadlines were confusing, which language lacked information, and which links produced errors without retaining a complete sequence of a querier's life. The institution did not lose responsibility by collecting less. It gained the ability to explain exactly what it observed, why, and for how long. That precision also makes a complaint, audit, and correction easier when the service fails.
Exceptional review needs limits and repair
Keeping some evidence can be necessary when an app gives a wrong instruction. It must be possible to know which version was active, which source was used, and which people may have received the same result. But investigation does not authorise opening every record or retaining conversations unrelated to the incident. A proportionate protocol defines the date, type of harm, authorised people, accessible data, and destruction date. Without those limits, a reasonable investigation can gradually become ordinary surveillance.
Human oversight is not a licence for curiosity either. Access must correspond to a function, be documented when it concerns sensitive information, and permit unusual downloads or queries to be detected. Separating service to people from technical analysis reduces unnecessary exposure. It also protects teams: a clear procedure prevents someone from improvising with delicate data under pressure and allows exceptions to be escalated to a person responsible for authorising them.
The OECD AI Principles and European data-protection rules stress transparency, accountability, and safeguards appropriate to context. In an everyday app, that can mean concrete actions: an account-free alternative where possible, a short period for logs, contracts that forbid unexpected uses, and an understandable way to challenge a result. There is no need to promise absolute certainty. There is a need to recognise what the system does, what it does not know, and where its authority ends.
Provider contracts deserve the same precision. They should say whether data train models, which subcontractors participate, where copies are hosted, how an incident is reported, and what happens when service ends. An organisation cannot transfer its duty of care into an opaque clause. Whoever presents an app to the public remains responsible for knowing the information journey and for being able to switch off, correct, or delete what should not be retained.
Well-resolved exceptions make a service more reliable
An organisation can test this idea through simple exercises. It can try to resolve a query with the least information possible, request a correction as if internet access were unavailable, review what happens when analytics cookies are refused, and ask what each provider can actually see. It can also compare a speed metric with messages about confusion or abandonment. These tests expose problems that a performance graph cannot represent.
Accessibility belongs in that review. A person who shares a phone, does not command the interface language, or cannot read a long notice may be exposed disproportionately. Alternatives must be usable, not decorative: telephone, in-person service, plain text, accessible formats, and a route to correct data without recounting intimate details. A screen that makes all help conditional on accepting tracking does not offer a meaningful choice.
A useful number keeps its place when it helps repair a service without claiming more of a life than necessary. Good performance is not measured only in clicks, average time, or completion percentage. It is also measured by the ability to ask for help without leaving an excessive trace, limit a permission without penalty, and receive review when automation is wrong. Privacy is not an obstacle to improvement: it is the boundary that prevents improvement from being confused with watching everything.
Institutional sources: Spanish Data Protection Agency, aepd.es; European Data Protection Board, edpb.europa.eu; National Institute of Standards and Technology, NIST AI RMF; Organisation for Economic Co-operation and Development, OECD AI Principles.
