Ambiguity is a special case of contradiction. It is found whenever there are multiple stakeholders who have their own views of the end product. As often as not it arises because there are fundamental differences of opinion between them. Circumstances (such as time constraints, turf issues, etc.,) that lead to the issues not being properly resolved lead to a compromise problem statement. Depending on how it is read, either view applies.
So what has happened here is an abrogation of responsibility and, as often as not, the issue will surface a long way down the project's path. The resolution of such issues is left to the development teams. If we are really unfortunate, one or other view prevails, so that the final product is then rejected by the opposing party right at the end of the project. Alternatively, the issue surfaces during critical design or construction points, or during testing. At the very least, this leads to expensive re-work or, at worst, conflict and the scrapping of the project.
Finding ambiguities always demands careful and painstaking reading of all the project documentation. In my experience, many turnkey projects have failed because, in the rush to close business, the bidders have failed to resolve the inherent ambiguities. This is even true of internal projects. Co-sponsors struggle to agree on key deliverables, and so couch the specification in such a way as to allow the specifications to be signed off, but to leave the conflict unresolved.