Image Upload in AI Chat: Photo Instead of Words

A customer stands in front of the boiler and sees a rating plate with fourteen characters, without knowing which of them is the model number. Another has a crack in the shower enclosure and does not know what the part is called. A third repeats an error message by meaning, not by wording. In all three cases, translating what is seen into what is written costs time and produces follow-up questions. Image upload in chat reverses the order: the visitor sends a photo, an assistant with image recognition reads what can be identified in it and asks exactly the one question that is still missing. That customer contact is the field where AI actually arrives in German companies is shown by the Bitkom survey on AI in the German economy from September 2026: 72 percent (Bitkom) of companies that use AI do so in customer contact, for example when handling enquiries. This article covers four robust use patterns, the limits of image recognition, a clean approach to data protection, technical hardening of the upload path and a staged rollout plan.

Enlarge graphic

Labels in the illustration

• Chat window
• JPG · 2.1 MB
• EXIF removed
• Photo: rating plate, blurred
• Which model is this?
• Probably series XY, built in 2019.
• Please let our team confirm it.
• A clue and a pre-qualification,
• not a binding diagnosis.
• Processing chain
• 1
• Check: file type, size, malicious code
• 2
• Strip EXIF and GPS metadata
• 3
• Recognition: clues, not diagnosis
• 4
• Match knowledge base and part list
• 5
• Hand over to the team with image
• Too uncertain? Passed on to a human.
• Market context
• 72 %
• of companies using AI apply it
• in customer contact (Bitkom)
• 80 %
• of common service requests via
• agentic AI by 2029 (Gartner)
• 57 %
• of companies with 20 or more
• employees use AI (Bitkom)
• Four robust use patterns
• 1
• Rating plate
• A photo instead of a mistyped
• type designation: model and
• year are proposed.
• 2
• Damage photo
• A first assessment with a clear
• caveat, instead of a visit for
• a two-minute look.
• 3
• Error message
• Screenshot from the software:
• wording, error code and
• version are in the image.
• 4
• Document
• Delivery note or dimensions:
• numbers and measurements
• move into the form.

Example: image upload in the chat assistant

Why a photo is often faster than any description

The bottleneck in support is rarely the answer. The bottleneck is describing the problem. Someone looking for a spare part usually does not know the technical term, only the function: the thing at the top that is dripping. Someone operating a system has the rating plate in front of them but mistypes the combination of letters and digits, because a zero looks like an O. Someone reporting an error message conveys the meaning, not the code. The result is always the same: the dialogue runs over at least three rounds, namely description, follow-up question, correction. Each of those rounds is an opportunity to give up, and each one costs handling time on your side.

A photo skips that translation. The visitor does not need to know what the part is called, they only need to be able to photograph it. An assistant with image recognition reads what is visible, compares it with the stored knowledge base and turns that into a pre-qualification: what is probably shown, which detail is still missing, which next step makes sense. The order matters: the image does not replace the conversation, it shortens its beginning. If you first want to understand what such an assistant already achieves without images, the basics are covered in the overview of what an AI chat assistant is.

The second effect weighs more than the time saved: a photo contains details nobody would have asked for. In the picture of a leaking tap you can incidentally see whether the connection is surface-mounted or concealed. In the screenshot of an error message, the software version sits in the window frame. On a delivery note, order and line item numbers are printed that would otherwise be typed out laboriously. Exactly this context is missing from a text-only chat, and that is precisely why the first answer without an image is so often another question.

Four use patterns that hold up in daily work

Not every image helps. The upload becomes robust where the photo carries information that is hard to put into words, and where that information connects directly to a data set you maintain anyway. Four patterns show up in project after project, across trades, retail, software and professional services.

The counter-check matters just as much. If your most frequent request is where an order has got to, image upload adds nothing, because the answer comes from the order status in your inventory system connected in the Custom package and not from a photo. For pure advisory questions, price enquiries and rescheduling, text remains the faster route. Image upload pays off where your team already writes the same sentence over and over: please send us a photo. If your staff write that several times a day, you already have the best available evidence of demand.

What recognition delivers and where the limit runs

The most important decision is made before the first line of code: an assistant that reads images provides clues and a pre-qualification. It does not provide a binding diagnosis or a price commitment. That separation is not only a legal precaution, it is the condition for the function being accepted internally at all. A foreman who sees a chat-based preliminary assessment used against him will push for it to be switched off. A foreman who receives a well-prepared request will defend it.

The way the conversation is run follows from this table. The assistant is meant to state its assessment with a visible caveat, name the detail it is missing and hand over to a human when uncertainty grows too large or the customer asks for something binding. For that transition to work cleanly, the same rules apply as in a text chat; how a handover to human agents works without a break is described in detail elsewhere. The only new part is that the image is handed over too, so the colleague does not have to ask for it a second time.

Solving data protection properly: EXIF, people, deadlines

A photo is not text. It regularly contains more than the sender deliberately shares. In the picture of water damage you see family photos on the wall, in a vehicle damage photo the number plate, in the picture of a house front the neighbours in the background. On top of that come the metadata in the file: capture time, device type and, for smartphone shots, very often GPS coordinates. Anyone offering image upload processes personal data on a scale a text field never reaches. The consequence is not to abstain, but to handle it properly.

• Strip metadata: before any further processing the image is re-encoded and freed of EXIF data. GPS coordinates, device identifiers and capture timestamps leave the file before it is stored anywhere.
• Purpose limitation: the image serves the handling of this specific request. It is not used to train models, not passed to third parties and not carried over into other analyses. That belongs in the contract, not only in a statement of intent.
• Deletion periods: a shorter period is appropriate for images than for text transcripts, because the risk is higher and the later benefit is lower. A fixed, automatically enforced period is clearly superior to a clean-up on demand.
• Data minimisation: under Article 5 of the General Data Protection Regulation, only data necessary for the purpose may be processed. In practice that means downsizing instead of archiving, a crop instead of the full frame, and no collection just in case.
• Special categories: photos from a health context, or images revealing religious or trade union affiliation, fall under Article 9 of the General Data Protection Regulation. In medical practices and clinics, image upload is therefore a project of its own with its own review, not an extra checkbox.
• Notice before the upload: right at the upload field, one sentence explains what happens to the image, how long it stays and that people in the frame are better left out. That notice increases willingness to use the function at all (Project experience).

Two things are explicitly ruled out. There is no biometric analysis, meaning no matching of faces and no identification of people in an image. And there is no emotion recognition. That is not only a matter of principle: Regulation (EU) 2024/1689 on artificial intelligence prohibits certain practices outright in Article 5 (AI Regulation), including biometric categorisation to infer sensitive characteristics and emotion recognition in the workplace and in education. Breaches of these prohibitions carry fines of up to 35 million euros (AI Regulation) or 7 percent (AI Regulation) of worldwide annual turnover. On top of that comes the transparency duty in Article 50 (AI Regulation): anyone interacting with an AI system must know it, including while uploading a photo. The article on labelling duties under the AI Regulation sets out the deadlines.

In its guidelines on the processing of personal data and in its opinion on AI models, the European Data Protection Board has repeatedly stressed that controllers must be able to show which personal data enters an AI system and on what legal basis it is processed there (European Data Protection Board). For image upload that means, very practically: extend the record of processing activities, put processing on a written contract, name the processing location and check whether a data protection impact assessment under Article 35 of the General Data Protection Regulation is required. For images from a health or employment context, the answer to that question is often yes.

Technical hardening of the upload path

An upload field is an open channel into your system. That is manageable, but it takes more than a file picker. The following measures are part of the standard scope and should be checked individually during acceptance rather than taken on trust from a provider.

• Restrict file types: common image formats and, where needed, PDF. What is checked is the actual file content, not the extension, because an extension can be renamed in seconds.
• Limit size and count: a limit per file, a limit per message and a limit per session prevent the upload from becoming a storage problem or an overload tool.
• Re-encode instead of passing through: every image is rewritten on the server. That removes EXIF data and at the same time any embedded content that has no business being in an image file.
• Scan for malicious code: files are checked before further processing and stored outside the web directory, without execution rights and without guessable paths.
• Treat text in images as content, not as an instruction: a photo can contain text that looks like an instruction to the system. That text is quoted and never executed.
• Check permissions: an image must not trigger an action the user could not trigger in the chat anyway. Permissions are tied to the session and the account, not to the content of a file.
• Rate limits and logging: uploads per minute and per hour are capped, conspicuous patterns are logged. That keeps the channel fast for real customers and unattractive for automated attempts.

The fifth point deserves its own explanation, because it is comparatively new. In its publication on generative AI models, the German Federal Office for Information Security describes indirect prompt injection as one of the central risks of such systems: attackers place their instructions not in the chat window but in content the model processes later (German Federal Office for Information Security). With an image upload this is particularly easy, because text can be written into a photo that a human dismisses as visual noise. The countermeasure is the same as for documents and web pages: strict separation of instruction and content, permissions tied to the session rather than to text, and no action without explicit confirmation. The article on securing assistants against prompt injection covers this in depth.

What the market currently expects

Context helps with prioritisation. According to the Bitkom survey on AI in the German economy from September 2026, for which 603 companies (Bitkom) with 20 or more employees were surveyed, 57 percent (Bitkom) of companies use artificial intelligence. Of the companies that use AI, 72 percent (Bitkom) apply it in customer contact, for example when handling enquiries. AI in customer contact is therefore no longer a pioneer topic but, according to Bitkom, the most common area of use. Anyone running an assistant today is not competing with their own contact form but with expectations customers have already picked up elsewhere.

The outlook from analysts is emphatic. Gartner expects agentic AI to resolve around 80 percent (Gartner) of common service requests without human intervention by 2029, with operating costs falling by roughly 30 percent (Gartner). The same analysts clearly dampen hopes of quick results, however: more than 40 percent (Gartner) of agentic AI projects are likely to be scrapped by the end of 2027, owing to escalating costs, unclear business value or inadequate risk controls. At the same time, the share of enterprise applications with agentic capabilities is expected to rise from less than 1 percent (Gartner) in 2024 to around 33 percent (Gartner) in 2028.

Between those two findings sits exactly the gap that image context closes. An assistant meant to see a request through on its own needs the details that make a case unambiguous: model, year of manufacture, error code, order number. As long as those details depend on a customer knowing a technical term and typing it correctly, a large share of cases stays incomplete. A photo supplies precisely that missing ingredient, and it does so without training the customer. Whether it works out in your own business can be traced later in conversation analytics.

A staged rollout with real test cases

Image upload is an extension, not a new build. That is exactly why a staged start pays off: one use case first, then the evaluation, then the next stage. A sequence that has proven itself in projects looks like this.

• Pick the case: exactly one use pattern, usually rating plates or error messages, because the result is easiest to verify there. Everything else waits.
• Check the data: without a maintained spare part, model or error code list, any recognition stays without consequence. That list is the real lever, not the model.
• Build and harden the upload path: field, limits, re-encoding, scanning, rate limits and deletion period. In parallel, extend the notice text, the privacy policy and the record of processing activities.
• Define the conversation: caveat, follow-up question, exit. These phrasings belong in the knowledge base and are agreed with the department, not written in isolation.
• Test with real customer photos: not with catalogue product shots, but with the photos that actually arrive by email: blurred, dark, skewed, half covered.
• Start small and evaluate: first for one page or one language, then read transcripts, then expand. The first two weeks reveal more than any amount of upfront planning.

The fifth point is where most projects fall short. A test set of fifty to a hundred real customer photos (Project experience) costs an afternoon of collecting and answers the decisive question before go-live: what does the assistant identify under real conditions, and how often does it have to admit it cannot tell. That answer weighs more than any demo with clean images, because it determines how the function is perceived in daily use. If you also want to know how answer quality is safeguarded in general, the method is described in the article on preventing hallucinations with the knowledge base. These six figures are enough to judge the first weeks:

• Share of conversations with an image, split by mobile and desktop
• Share of images from which a usable detail was obtained
• Number of follow-up questions until the request is complete, with and without an image
• Share of cases in which the assistant honestly handed over to a human
• Share of uploads that failed on size, format or scanning
• Handling time in the team for requests with an image compared with requests without one

Integration, effort and what XICBOT takes on

At XICBOT, attachments are a setting on the support assistant and not a second system. When it is switched on, visitors can attach photos and PDF documents in the chat. Every file is checked on arrival by its content rather than its extension or file name, and it is delivered as a download instead of being opened in the browser. It stays with the conversation and, once the visitor leaves contact details, with the request in your business inbox, so nobody has to ask for the photo a second time. The assistant does not evaluate the image content itself; your team classifies it and checks it against your spare part or model list. Connection to existing systems runs through the established integration, and storing the files on servers in Germany is part of the data protection and hosting concept.

The effort depends less on the upload field than on the data foundation. If model and spare part lists are maintained, the extension is manageable and can be added later as a custom function without rebuilding the running chat. If that foundation is missing, preparing it is the larger part of the project and at the same time the part that pays off even without images. Related extensions follow the same pattern: how customers speak their request instead of typing it is described in the article on voice input in AI chat, and how the same approach works internally in the text on the internal AI assistant for employees. Internally in particular, image upload plays to its strengths, because fitters and warehouse staff photograph things anyway before they write. For businesses with many on-site appointments, the assistant for trades and crafts is worth a look as well.

If your team already asks for photos by email on a regular basis, that is the obvious first trial: switch on attachments for one assistant and count after a few weeks how many requests with an image arrive complete. How a request takes shape in the conversation and lands in the inbox together with its attachment is shown by the lead assistant.

Frequent questions