In this piece
ING-B: AI for electrical engineering document review
A revised electrical specification needs a checked record of what changed. For an independent ING-B AI opportunity analysis, we would first test a source-linked requirements and revision register. An engineer would resolve ambiguous changes against the original passages, then decide what enters issued documents. The value of that experiment still needs measurement.
Public sources checked: . This research used published service descriptions and technical guidance. We had no access to ING-B project files or staff interviews. No AI system was tested. The proposed workflows describe experiments we would investigate in comparable work, without asserting an internal need or a missing capability at ING-B.
Where could ING-B use AI for electrical engineering document review?
ING-B’s published services make tender review, lighting evidence and handover documentation concrete subjects for an AI experiment. Its service overview covers tender preparation and bid review alongside site supervision. That identifies document families to investigate; it does not establish how the company manages them internally or whether assistance would save time.
The ING-B FAQ lists tender specifications, installation and wiring plans, and invoice review. It also describes Dialux lighting calculations, DALI/KNX integration and BIM planning on request. Those statements do not establish which project-file formats or integrations a pilot could access.
The public brochure’s service list, printed pages 04-05 also covers calculation and documentation. A draft finding should retain its source and review decision.
| Proposed experiment | Reviewable output | Condition for choosing it |
|---|---|---|
| Requirements and revision review | Changed passages with document versions and open questions | A specialist can define the expected findings |
| Lighting-product evidence comparison | Exact product variant, stated value, unit and source | An approved brief and applicable manufacturer documents exist |
| Handover evidence check | Missing, mismatched or unresolved documentation | The project has an agreed delivery checklist |
Which AI opportunity would we test first?
We would start the ING-B example with a requirements and revision register. A revision register is a table that records each changed requirement with its source versions and review decision. For a fixed document pair, an engineer can record the expected findings before evaluating the assistant’s draft.
Choose one document family and one reviewer. Fix the revision pair and the sections in scope. Ask the assistant to collect candidate differences. Compare extracted quantities and identifiers with ordinary code, preserving their units. Keep the original passages beside each finding.
Export the review table without write access to issued documents or live equipment. Consider integration after measuring the value of that output.
What should a revision register catch?
For the ING-B experiment, a revision register should separate changed values, omitted requirements and uncertain identities. Every identifier and product label in the following fixture was invented for the example. It is a proposed acceptance example, not ING-B project data or electrical-design advice. No AI system was run against it for this article.
Revision A, section 2.4: Room R-204: supply 12 luminaires of type L-07. Connect them to control group C-3.
Revision B, section 2.4: Room R-240: supply 16 luminaires of type L-07.
| Observed difference | Expected draft finding | Decision still needed |
|---|---|---|
| 12 becomes 16 luminaires | Quantity changes by 4, preserving both passages | Engineer confirms the intended quantity and scope |
| Control group C-3 is omitted | The earlier control requirement remains visible as an unresolved deletion | Engineer confirms whether its removal is approved |
| R-204 becomes R-240 | Room identity is uncertain | Reviewer checks the approved room mapping |
The quantity arithmetic is 16 − 12 = 4. That does not prove the two passages concern the same room. An assistant that reports only the count has missed a separate review question. It must preserve the identity ambiguity until someone resolves it.
Preserve each passage’s filename, revision and section. Store the draft finding separately from the reviewer’s decision. If text extraction cannot read a page, the register must show an incomplete comparison. An empty finding list cannot stand in for a completed check.
How could AI support lighting-document review?
For lighting-document review, we would test an evidence table tied to exact product variants and an approved brief. ING-B’s lighting-planning page describes calculation, simulation, technology selection and technical documentation. An assistant could prepare candidate evidence for those decisions, while a qualified reviewer checks applicability and performs the necessary engineering work.
Each row needs the exact product code and supporting passage. Retain the original unit and any qualifying footnote. A value for a similar luminaire must not fill a gap in the selected variant’s evidence. Mark the missing value and ask for the applicable document.
The engineer retains responsibility for lighting calculations, suitability assessment and design approval.
What could a handover evidence check prove?
A handover evidence check can organize documents against agreed requirements, but it cannot establish that physical testing occurred. ING-B’s building-management services include technical documentation and commissioning support. A proposed assistant could collect candidate records and flag gaps for review, keeping document completeness separate from the specialist’s acceptance of actual results.
Use the project’s approved delivery checklist. As a separate Austrian public example, BIG’s documentation requirements address room and asset identifiers, document naming and storage, and say the required scope must be agreed for the specific project. We have not verified a particular ING-B assignment or its applicable requirements.
| Field | What the reviewer needs |
|---|---|
| Requirement | The agreed checklist item and its source |
| Identity | Equipment or room identifier, document revision and location |
| Evidence state | Present, missing, conflicting or unreadable |
| Result and acceptance | Observed result, responsible reviewer and recorded decision |
Test a fictional row where a commissioning instruction is present but the observed-result field is blank. The expected output is a missing-result flag. The assistant must not turn an instruction into a successful test or copy an outcome from another equipment identifier.
Where does BIM information checking fit?
For the ING-B example, BIM information checking is a later option with suitable model data and approved information requirements. The buildingSMART IDS user manual describes specifying and checking simple information requirements from IFC models. That supports a narrow information-checking experiment; it does not establish which exports or validators ING-B uses.
An engineer could approve the information requirements, run a dedicated checker against a specified IFC revision and ask AI to explain its issue list. Attach each explanation to the element identifier and original rule result. Keep overall engineering validation separate. This information check does not establish collision freedom or a successful commissioning result.
If the proposed review later needs a connected retrieval application, the production RAG readiness checklist addresses that broader implementation decision.
How should the first experiment be evaluated?
Evaluate the proposed ING-B document-review experiment against expected findings and the work left for the engineer. NIST’s Generative AI Profile recommends checking generated sources and citations and avoiding performance extrapolation from narrow assessments. For this pilot, retain the original evidence. Reserve examples that were not used to refine prompts.
- Have a specialist record the expected findings before running the proposed test.
- Include the fictional quantity, deletion, identity and missing-result cases, plus unchanged documents to expose false flags.
- Try unreadable pages and conflicting revisions. Require the output to identify the gap.
- Check every claimed source passage and record omitted findings and incorrect flags.
- Measure all human work through to acceptance, including corrections and failed attempts.
An invented requirement fails the test. So does silently resolving a room mismatch or asserting a result without evidence. A clean small test leaves future reliability unproven. Before using representative nonpublic files, agree access and processing with their owner.
When would the business case justify another step?
The business case improves only if assisted review reaches an accepted result with less total work at the required quality. Compare similar tasks, including preparation and corrections. Keep model waiting separate unless it occupies the reviewer. Include implementation and ongoing software costs. Document upkeep and repeated evaluation also consume the capacity the business case is meant to release.
Net human time saved per comparable task = manual human time − all human time in the assisted workflow. Measure task volume before scaling that figure. ING-B’s actual handling effort is unknown, so we give no savings or payback estimate.
The AI pilot kill-or-scale scorecard covers the later operating decision. The internal AI assistant cost guide helps identify budget categories after the source scope and deployment requirements are known.
What would a useful first brief contain?
For the ING-B example, specify the evidence a reviewer needs to accept one defined output. Choose the revision pair and agree the rejection cases before comparing manual with assisted review. Require less total effort per accepted review before expanding.
Use the AI automation project brief to record the acceptance conditions and review responsibility. Agree usable exports. The separately published Twinsoft AI case study provides adjacent delivery context; it does not establish an ING-B implementation.
Our technology consulting service can turn a bounded build-or-buy question into a written recommendation. Scope one review task with the person who approves the result.