The first question must arrive before the tool. Faced with an automated response, the opening question is not how much time it saves, how many messages it classifies, or how intelligent it appears. The question is which need it serves, what harm it can cause when it is wrong, who has an exit when the answer makes no sense, and who answers for the decision. This manifesto offers a simple rule for everyday artificial intelligence: no automation should take the place of a well-formed human question.
Automation already shapes ordinary gestures. It sorts email, recommends schedules, filters requests, drafts replies, translates notices, and decides which information appears first. Because it is so close, it can seem neutral. Yet every automated response sets priorities, assumes facts, and turns a complex situation into a category. The problem is not only found in large systems or extraordinary headlines. It also appears in the short answer sent to a worried person, the form that reads an absence as an error, and the assistant that offers a convincing solution without knowing the context.
Ask before automating#
The prior question should describe the problem without selling an answer in advance. It may be: “Which task is being delayed, and why?”, “What information do people actually need?”, or “Which part requires judgment, empathy, or accountability?” Asking this way keeps a tool from becoming the definition of the problem. If an office receives repeated questions, the answer may be a better page, a clearer letter, or longer service hours. Installing a chatbot can fit some cases, but it is not the default response.
The prior question should describe the problem without selling an answer in advance.
A good question also names the boundary. Some decisions should not be handed to a system that infers patterns: a health emergency, a request for social support, a discrimination complaint, or a delicate employment situation requires people able to listen, seek clarification, and accept responsibility. Speed can be valuable, but it is not the same as care. When the cost of an error falls on someone with less time, fewer resources, or less access to help, the standard must be higher.
Before a tool is launched, it is useful to write a short record: specific purpose, affected people, data used, expected response, known risks, human route, and review date. This record needs no technical language to be useful. It makes the promise of efficiency meet the conditions of use. It also lets a service explain why automation exists and what someone can do when it fails. A tool without a bounded purpose tends to expand into tasks for which it has not been assessed.
Case 1: the message that looked like a ruling#
A housing organization added an assistant to answer common questions about rent support. The system recognized words such as “documents,” “deadline,” and “rejection,” and returned links to information pages. In the first weeks it reduced some calls. Later, several people interpreted its replies as an official ruling: after reading that a document was missing, they stopped filing an application; after reading that a deadline had passed, they did not ask about an exception contained in the rules. The automatic sentence was clear, but it had no authority to close those situations.
The review began with a different question: “What does a person need to know in order not to lose a right by misunderstanding an answer?” Opening text was changed to say that the tool gave general guidance, not decisions. Questions about refusals, expired deadlines, and incomplete documents went directly to a staffed channel. Every automated reply included the information update date and a visible link to request review. For two months, the team reviewed diverted contacts, abandoned applications, and corrections made by staff.
The case shows that transparency is not achieved by adding a tiny label saying “generated by AI.” It means designing a reply so nobody must guess its scope. If a sentence can affect access to a right, it must state what it knows, what it does not know, and how to obtain human confirmation. Automation continued to have a limited role, but stopped impersonating a decision it could not make.
Case 2: calculated priority that hid an emergency#
A maintenance service used a system to order reports received through an application. The model gave priority to incidents with certain words and areas with more recent reports. The intention was to organize work better. Yet a report about a damaged ramp fell down the list because its description was brief and did not match risk terms. The sender was writing from a phone with little battery and did not attach a photograph. Classification looked objective, although it had turned a lack of detail into a lack of importance.
The right question was not “How can the model score be improved?” but “Which kind of report cannot wait for the model to be certain?” Safety categories were defined that could never be resolved by automated classification alone. Ambiguous reports entered a rapid review queue, and the application allowed a physical barrier to be marked in a few words or through a call. The team published the priority criterion and retained a change record without keeping more personal data than necessary.
The correction did not remove every automation. It used automation to support repetitive ordering, not as permission to ignore uncertainty. Review times for ambiguous alerts, reopened incidents, and reports arriving through alternate channels were also measured. A responsible system does not claim to know the world through a score. It recognizes when it lacks context and hands the situation to someone able to obtain it.
Case 3: the quick draft that changed the tone#
A service team began using a generative tool to draft replies to complaints. The draft saved minutes and maintained an orderly style. However, several responses began to repeat phrases such as “we regret the inconvenience” beside overly certain explanations about facts still under investigation. Some people received text that was grammatically correct and cold in meaning: it did not acknowledge the particular difficulty or explain what would happen next. Writing speed had displaced the responsibility to verify content.
The team agreed that no draft could be sent without human reading and that complaints involving harm, urgency, or possible discrimination would not be drafted with generative templates. A checklist was created: confirm facts, remove unverified claims, use plain language, state the next step, and name a person or response channel. Samples were periodically reviewed for errors, unsuitable tone, and invented references. The team was also told that use of the tool would not measure individual productivity.
The lesson is not that a draft is always unacceptable. It is that an automatic text has no moral or administrative duty to answer for its words. That duty remains institutional. A good process uses mechanical assistance for low-risk tasks and keeps human time for listening, checking, and repair. When an organization answers with a machine, it must be able to say who reviewed the answer and how it can be corrected.
Design exits, not dead ends#
Every automated response needs a clear exit. A hidden button or generic address that never receives a reply is not enough. The exit must be accessible from the moment the response appears, work on a phone, accept plain language, and not require someone to repeat their whole story. It may mean speaking to a person, requesting review, saving a case for later, or using a non-digital channel. Choosing a human route must not be treated as user failure or as an expensive exception to discourage.
Exits matter especially when a system works with incomplete data. A model can confuse names, misunderstand a local expression, fail to recognize an accessibility need, or respond with old information. The affected person does not need to know which technical error happened in order to ask for help. It is enough to say, “This does not answer my situation.” That sentence should open a review, not another loop of automated options.
Accessibility is part of this responsibility. An interface accepting only long text excludes someone who needs to call; an explanation full of technical words excludes someone unfamiliar with the procedure; a short deadline excludes someone who depends on support. Responses need testing with different devices, languages, screen readers, connections, and time conditions. The test does not measure people’s skill. It discovers where a service demands needless burden and how it can reduce it.
Data protection is required as well. The convenience of pasting a complete query into an external tool can expose information unnecessary for producing a draft. Only indispensable data should be used, the purpose should be explained, access should be limited, and retention periods should be set. Sensitive conversations must not become training or evaluation material without a clear basis and understandable information. Minimization is not an obstacle to innovation; it prevents a useful answer today from creating a silent risk tomorrow.
Govern the everyday response#
Governance does not mean producing a long document nobody reads. It means assigning visible responsibilities. Every tool needs a person or team responsible for its purpose, updates, and incident handling. There should be a review calendar proportionate to risk and a way to pause the system if serious errors appear. Records should make it possible to reconstruct which version was used, which rules were active, and how a response was corrected, without turning oversight into surveillance of users or workers.
Evaluation must look beyond technical accuracy. It is useful to ask how many people found a human exit, how many responses were corrected, who abandoned the process, which groups faced more difficulty, and what harm was avoided through review. Numbers alone do not explain causes, so they should be combined with voluntary and safe conversations. If automation saves time for a majority but raises barriers for a minority, that result is not complete success.
Public information should be proportionate and understandable. An organization can explain which task a system supports, what data it uses in general terms, which decisions it does not make, and how to request review. It need not reveal details that enable abuse, but it cannot request blind trust either. Explanation corrects expectations, detects mistakes, and allows informed debate. Opacity often protects the tool; useful transparency protects people.
This manifesto defends one practical habit: pause before adding artificial intelligence to a workflow and ask the question the tool cannot ask for itself. Who does it help? Who can it harm? What happens when it fails? Who listens? When will it be reviewed? The answers will not always lead to automation. Sometimes they lead to simpler rules, more support, better writing, or a conversation. That possibility is not delay; it is the condition of a responsible decision.
Institutional sources that support this standard.
The NIST AI Risk Management Framework provides a framework for governing, mapping, measuring, and managing artificial-intelligence risks. The OECD sets out principles for robust, transparent, human-centred systems. The European Commission explains the European regulatory framework for artificial intelligence. UNESCO presents its recommendation on AI ethics and rights protection.
These sources do not replace the responsibility of each service. They offer a common language for recognizing risks, documenting decisions, and reviewing consequences. The decisive practice remains local: listen to those receiving the answer, allow a classification to be challenged, and change the process when evidence requires it. Everyday artificial intelligence will be more trustworthy when it is not presented as inevitable authority, but as limited, reviewable, situated assistance.
The first question must arrive before the tool because an automated response is never alone. It carries a choice about time, attention, data, and power. Asking that question creates room for care; omitting it lets the tool decide which problem deserves to exist. The manifesto ends where every project should begin: with a question sufficient to protect people before accelerating the system.
